implement solubility model into foamAgeing application

[japaf]

If I am correct, several things need to done.

• Detailed solubility model should be automatically compiled when foamAgeing application is compiled.
• Solubility model module in the root of foamAgeing needs to be created and imported by initModels. Ageing application expects that these models will be created:
  • "solubilityPol[A=Air]"
  • "solubilityPol[A=CO2]"
  • "solubilityPol[A=CyP]"
• Conversion to compatible units must be carried out between Solubility and Ageing models.

[henrus]

@1) Initialisation (and compilation) can be deferred to the time when the model is actually used from within the macroscopic code. An example is in example/twoTanksAutoInit. This is fully automatic (ie. no initialisation on the outside is required), but the macroscopic code would stop on every call to a 'new' model. We can add additional functions to the interface library if this becomes a problem
@2) Yes, you need to import the solubility model
@3) Not sure what you mean here: Shouldn't we all use SI units?

[sigveka]

1. Are you both talking about the same compilation?
   • My impression is that Pavel means the "detailed code", whereas Henrik means the "surrogate".
   • I was planing to modularise the application to the extent that foamAgeing and foamConductivity becomes "models" that are both imported into an application. The nice thing about Fireworks is that it executes the programs/scripts in one directory; therefore you do not have to think about where to pick up "input/output" files only agree on the structure. (I have not understood how this works with distributed computing.)
2. I can push a version of the solubility model that you can import into workflow using import US_Solubility_Model.
   • I am having a internal battle for how to organise this, but I think I will add a new directory "models" to the "root". The first directory will then contain: applications, models, examples, src, Readme.md. Objections?
3. I think he means e.g. dL -> m³

[henrus]

@1) I am talking about compiling Fortran/C against the interface library. Distributed computing is a complex matter.
@2) Hmm. I think I would like to keep the PUFoam self-contained and avoid mixing the models from examples and applications. How about

applications/PUFoam/PUFoam0D/0D_code.C
applications/PUFoam/PUFoam3D/3D_code.C
applications/PUFoam/models
examples/twoTanks
examples/twoTanksAutoInit
examples/models
src

In order to avoid setting PYTHON_PATH we could simple walk down the tree and search all model directories we can find.

@3) dL is not SI

[japaf]

@1) I was talking about the detailed model. Sorry for the confusion. I wanted to do cmake . and make only in the application I want to use. Having to explain in README of foamAgeing that if they want to use PC SAFT model they need to go to different folder, open a README there and find out how to compile it seems unnecessarily complicated to me.
@2) Breaking down foamAgeing into individual models makes sense to me. I am not sure about the best structure. My idea is following:

• applications/PUFoam/models would contain folders with detailed models of foamConductivity, foamAgeing, PC_SAFT_Solubility, etc.
• applications/PUFoam/workflows would contain what we have as "applications" now, i.e., foamAgeing and foamingProcess. All python scripts would still be there. Theoretically, python model modules like foamConductivity.py can be also moved to models folder. However, I think that these files are still application-specific. For example, even though both foamAgeing and foamingProcess would eventually contain very similar solubility.py file, we might want to initialize solubility for different species etc.

Ordinary user would interact only with workflows folder (changing input files, running simulations and looking at results).

@3) This is a long standing issue between me and Jonas about the definition of solubility. This was mentioned only for completeness. It can be fixed once the models are communicating.

[sigveka]

1. My ban then, you are talking about the same thing.
2. Very reasonable argument.
   • At the moment I am not considering dist. comp. I am just being
     aware that at some point it will come. I know exactly nothing
     about it so I
     am not of much assistance, but I am open to receive input if my
     implementation will make it more difficult to realise.
3. Of course, however personally I was expecting this to be an issue,
   albeit a small one, nevertheless.

​

On 30 September 2015 at 12:15, Henrik Rusche notifications@github.com
wrote:

@1 https://github.com/1) I am talking about compiling Fortran/C against
the interface library. Distributed computing is a complex matter.
@2 https://github.com/2) Hmm. I think I would like to keep the PUFoam
self-contained and avoid mixing the models from examples and applications.
How about
applications/PUFoam0D/0D_code.C
applications/PUFoam3D/3D_code.C
applications/PUFoam/models
examples/twoTanks
examples/twoTanksAutoInit
examples/models
src

In order to avoid setting PYTHON_PATH we could simple walk down the tree
and search all model directories we can find.

@3 https://github.com/3) dL is not SI

—
Reply to this email directly or view it on GitHub
#25 (comment)
.

[japaf]

#41 is partial solution to this issue.
@1) compilation now works from foamAging through ./build script. I didn't manage to use the makefile provided by Jonas, so I added some necessary CMake files. There are two copies of PC_SAFT. I use the code from PythonModule_and_DetailedModelCode/DetailedModelCode. Is this correct?
@2) I copied and modified modSolubility.py one folder up, so that __init__.py can see it. I used index sets to create the desired models. However, I still have few issues with that.

• PC_SAFT model expects that I provide composition, but composition is not an input to surrogate model. How should I treat it in the ExactTask? Should the composition be assumed constant for the whole simulation? In that case, we could load it from a file/recipe. Otherwise, I guess change in the surrogate function is needed.
• PC_SAFT model doesn't converge for arbitrary initial temperature. I don't think that modena takes into account that detailed model can fail in some cases, so I think it's worth mentioning.

@3) I don't think that molar mass of PU will be part of the recipe. It is rather a PC_SAFT parameter. Consequently, the foamAging model will not know this value. I think we have two options:

• Define solubility in (g solute / g PU) and don't provide molar concentration of PU (it can be calculated in PC_SAFT model from density of pure PU under the assumption that only small amounts of solute are present). Input of solute can remain in molar concentrations.
• Keep definition of solubility and composition as it is, but make molar mass of PU an input to PC_SAFT model. But who should define the molar mass of PU for the PC_SAFT?

Personally, I think the first option is better.

[JonasMairhofer]

@1) Yes, this is the correct code. However, I cant think of a reason why the makefile shouldnt work. If you open it, you will find that it doesnt contain much that could go wrong. On the other hand, if it works with cmake now, thats better anyway.

@2) You are right, I will have to add composition as an additional input argument to the surrogate model. Assuming it to be constant during the simulation would be too much of a simplification.
Regarding the convergence of PC-SAFT, yes, unfortunately this happens and there is no quick fix for it.

@3) Both way are possible, we should discuss this next week at the meeting in more detail.