Modelling a custom PFR model using DAEs

[abhi24x7]

Dear IDAES community,

I just started using the framework a week ago and I would like to thank all the concerned developers for working on the tutorials and examples, they really gave me insights about how the platform works. It was a really good guide.

Now, through this thread, I am seeking your help to make a custom packed bed PFR model with my own Mass & Energy balance equations and rate equations (which are not simple Arrhenius model), I just want to know how can I declare the same?

Thank you very much!

[andrewlee94]

Hi @abhi24x7, welcome to IDAES. It seems there are two parts to your question, and it sounds like you are trying to do a fairly custom model.

Firstly, on the topic of the reactor itself. It is possible to use the core PFR model and turn off the mass, energy and/or pressure balances if you desire, but at that point you might be better off asking if it is better to use a completely custom model. Depending on how you want to write the reaction model, you might also need to change how the extent of reaction is defined - the PFR uses extent = area*rate (i.e. a volumetric definition of reaction rate). To turn off the material balances, you can do m.fs.pfr = PFR(material_balance_type=MaterialBalanceType.useDefault) (and similar for the energy and momentum balances). However, before you start working on this, it might be a good idea to discuss what it is you want to do in more detail so we can give some more detailed suggestions on how to go about it (specifically, what is it you want to customize about the mass and energy balances).

On the topic of the reactions, you can write your own custom reaction package. A simple example can be found here: https://github.com/IDAES/idaes-pse/blob/main/idaes/models/properties/examples/saponification_reactions.py. This uses a simple Arrhenius power law model, but you can replace those equations with those of your choice. As long as the final rate is on a volumetric basis (e.g. mol/m^3), it will fit into the core models.

[ColbyCodey]

@andrewlee94 ,
I have been dealing with similar scaling issues trying to model a combined cycle system very similar to the ngcc example. I tried using a scaling process similar to that used in the ngcc example, but I still had a large number of poorly scaled variables and constraints according to the diagnostics, so I have been trying to implement some of what you recommended in your April 8th reply.

I started by solving my unscaled model (it does not converge after 200 iterations but seems close with only a few small residuals), then using some of the IDAES scaling tools to automatically scale the variables, and adding a scaling factor of 1 to any variables with a value of 0.

I then tried to use * set_constraint_scaling_harmonic_magnitude() on the whole model but it is running into issues. I added some code to the _set_sf_har_mag() function to print the component name before the NominalValueExtractionVisitor is called, as this is where the error occurred. More specifically, the error occurs in the _get_nominal_value_for_sum_subexpression() function:

I edited this function as well to see where the str data is coming from:

def _get_nominal_value_for_sum_subexpression(self, child_nominal_values): # function edited to identify issues with str present causing error with sum
        total = 0
        for i in child_nominal_values:
            print(f"\t{i}")
            if type(i) is not str:
                total += i
        return total

This has allowed me to identify that certain components have child nominal values that are not numbers, and even with the change to ignore these values, these components typically have some type of error occur when evaluating expressions as well (see output below):

Component: fs_hrsg.ECON.delta_temperature_in_equation[0.0]
	1
	1000
	0.001
	1
	0.001
	0.018015268
	1
	1000
	0.001
	1
	H2O
	985.177782734931
	7079.99998895492
	[c:\...\anaconda3\envs\idaes-tea\lib\site-packages\idaes\models\properties\general_helmholtz\components\parameters\]
ERROR: evaluating object as numeric value: t_hp_func(0, 985.177782734931,
7079.99998895492, 0)
        (object: <class
        'pyomo.core.expr.numeric_expr.ExternalFunctionExpression'>)
    [WinError -1073741784] Windows Error 0xc0000028

I am just hoping to get a good rough start on scaling with this. For now, I can try and work around these problematic components and manually set the scaling. I have seen this with a custom constraint I made as well as the delta temperature in equation for the HeatExchanger model so far. If you could help me to identify if I am doing something wrong that is causing this I would greatly appreciate it.

Thanks

[andrewlee94]

@ColbyCodey That is rather odd, and it looks like there are two separate issues here. Firstly, how strings are ending up in the expression walker, and secondly why the external function is not being evaluated correctly. Do you have a simple example that replicates the issue? That said, this tool is in the process of being deprecated so I am not sure how much effort we will put into maintaining it.

Whilst this is still in the draft stage, this PR might help you: #1429 - this is what will eventually replace the tools you are looking at. This is the draft of our new scaling toolbox, which adds some additional methods that are often better the the harmonic mean (from experience, the inverse of the maximum constraint magnitude works best). It also has some draft documentation, and a tool that will compare a few different ways of doing constraint scaling for you.

[ColbyCodey]

@andrewlee94 ,
I put together a simple model with just the HeatExchanger unit model, initialized and solved at conditions similar to what I am working with, then went through the scaling process I talked through above:
set_constraint_scaling_harmonic_magnitude_issues.pdf
This is the same error I run into with my full model.

I'll start looking into the new scaling toolbox. Love what I am seeing so far.

[andrewlee94]

@ColbyCodey I worked out what the issue was, and if was an edge case we had overlooked when working with external functions (occasionally they will have an input that is a string). I suspect the new scaling toolbox might suffer from this same issue, and if so I will update that pull request accordingly.

As a patch, you can replace lines 1476 to 1479 in idaes.core.util.scaling.py with:

input_mag = []
    for i in child_nominal_values:
        if isinstance(i[0], str):
            input_mag.append(i[0])
        else:
            input_mag.append(self._get_nominal_value_for_sum_subexpression(i))

[andrewlee94]

@ColbyCodey I just opened a PR with the bug fix: #1487