[pattim]

Based on the units definitions in species files, are OF Species Units kg/kg or mol/mol? Either way they are [0,0,0,0,0,0,0], but the results are very different, depending. Searched the internet, found only one elliptic reference saying it's mass fraction (kg/kg). Can the authors verify?


Thanks! pattiM


EDIT: The nomenclature [0,0,0,0,0,0,0] for dimensions of output files thus contains some ambiguity. I'm sure the inventors of that nomenclature didn't intend built-in ambiguity for the null state. I wonder if there's a way to fix the null case(s)? This seems a little silly, but it could work for the simple case (are there others in physics/chemistry?): [1-1,0,0,0,0,0,0] vs. [0,0,0,0,1-1,0,0] Rigorous, but maybe silly?
I only point this out because we chemical physicists think in mols vs. fluid dynamicists who think in mass. Also, mole = the "quantity" unit in available OF docs... so that seems a tad ambiguous for the null case.

[Pappelau]

The unit definitions of OpenFOAM are indeed MASSfractions !
you can always search in the sourcecode: https://cpp.openfoam.org/v10/classFo...676e8efa5290cd

[pattim]

Originally Posted by Pappelau

The unit definitions of OpenFOAM are indeed MASSfractions !
you can always search in the sourcecode: https://cpp.openfoam.org/v10/classFo...676e8efa5290cd

Thank you! And thank you for the link to source code! I had looked a lot on the "source" reference site(s) and never found explicit C language - but this link took me right to some C code (at least header files and the like), and it looks pretty well-commented. I guess there aren't good docs for OF, really, just source and the wonderful tutorial examples in the installation.

I thought I remembered, years ago, online demonstration(s) of examples, but that appears to be gone (at least g**gle and ddg don't turn them up). Docs are tough (read: expen$ive) to maintain.

It's such amazing software, I wish the OF Foundation provided a paid-for support plan for some of the more gnarly questions.

Best Regards,
PattiM

[Yann]

Originally Posted by pattim

It's such amazing software, I wish the OF Foundation provided a paid-for support plan for some of the more gnarly questions.

Hello,
If I may step in, I think they do: https://cfd.direct/openfoam-support/cfd-support/

No idea about pricing but if you are interested I guess it is worth contacting them.

Regards,
Yann

EDIT: for people using the ESI-OpenCFD branch, there is a similar service: https://www.openfoam.com/products-se...ftware-support

[pattim]

Originally Posted by Yann

Hello,
If I may step in, I think they do: https://cfd.direct/openfoam-support/cfd-support/

No idea about pricing but if you are interested I guess it is worth contacting them.

Regards,
Yann

EDIT: for people using the ESI-OpenCFD branch, there is a similar service: https://www.openfoam.com/products-se...ftware-support

Wow - thanks Yann! I had no idea about these sorts of details - for me, websearches nowadays aren't what they were a decade ago, apparently - I guess I'm just not keeping up somehow. I'm curious how many branches of OF are there, and how they differ in capabilities.

One of my big, current questions is how salome-platform interacts with OF. I used to use s-p to do unstructured grids of complex geometries and being able to run OF on such grids would be useful, but I'm pretty sure not all OF solvers support unstructured Tet grids.

[Yann]

Regarding the OpenFOAM branches, I like this graph which is getting old but still good to get a big picture of the OpenFOAM world:



The above picture dates back to 2016, here are the current versions:

• foam-extend: foam-extend-5.0 (2022-09-20)
• OpenFOAM foundation: OpenFOAM-v10 (2022-07-12)
• ESI-OpenCFD: OpenFOAM-v2212 (2022-12-20)

You also might like to read this thread: OpenFOAM.com versus OpenFOAM.org: Which version to use?

Long story short: the ESI-OpenCFD and Foundation branches are moving apart so nowadays you should be careful to the versions when searching for help on the internet because functionalities, models and syntax may vary between both branches.

Unfortunately I cannot help with Salome since I don't use it but I'm pretty sure other users here might help!

Yann

[pattim]

Thanks again for the great info and links. Things-computer are changing rapidly. I use whatever branch is in the repos for OpenSuse LEAP/Tumbleweed. I guess I'll have to check the repo database - also study that picture more.

The version I have says v2212, and lists OF.com - So I guess that settles it as the ESI version. Going to have to search for sonic/supersonic, density-based solver with chemical reactions (all in one) between the two primary (.com/.org) versions. I don't yet know how deep the differences go, but I haven't seen any discussion elsewhere (salome, python, etc., sites) on differences, so the differences probably aren't huge... and that seems likely as commits are made between the two major versions. Probably whomever offers a less expensive support contract would be just fine for both versions. (maybe I shouldn't be saying that out loud!)

Thanks again for providing a high-level overview!

[Yann]

Differences between .org/.com versions are getting bigger and bigger.

The OpenFOAM foundation is dedicating a lot of time into rationalizing and refactoring the code, we are talking about merging solvers, deprecating/replacing functionalities (for instance NCC has been introduced to replace AMI). They are putting effort into developing modular solvers through the foamRun/foamMultiRun applications, which could radically change the way we use OpenFOAM.

ESI-OpenCFD on the other hand develops techniques/models/solvers which are not implemented in the Foundation branch (Overset and Adjoint Optimization for instance)

On a more general usage: if you have a case running in one of the .org/.com version, you won't be able to run it on the other branch without adjusting your case setup due to different functionalities, options, file/parameters names, syntax... It's not radically different (most of the models and solvers are still the same) but the difference lies in the more or less small details spread everywhere in the code.

Anyway, it's worth spending a bit of time trying both branches on your own cases in order to see if one is providing useful stuff which are not available in the other branch.

[pattim]

Originally Posted by Yann

Differences between .org/.com versions are getting bigger and bigger.

The OpenFOAM foundation is dedicating a lot of time into rationalizing and refactoring the code, we are talking about merging solvers, deprecating/replacing functionalities (for instance NCC has been introduced to replace AMI). They are putting effort into developing modular solvers through the foamRun/foamMultiRun applications, which could radically change the way we use OpenFOAM.

ESI-OpenCFD on the other hand develops techniques/models/solvers which are not implemented in the Foundation branch (Overset and Adjoint Optimization for instance)

On a more general usage: if you have a case running in one of the .org/.com version, you won't be able to run it on the other branch without adjusting your case setup due to different functionalities, options, file/parameters names, syntax... It's not radically different (most of the models and solvers are still the same) but the difference lies in the more or less small details spread everywhere in the code.

Anyway, it's worth spending a bit of time trying both branches on your own cases in order to see if one is providing useful stuff which are not available in the other branch.

Wow, Yann - you *really* seem to have a clear vision of what's going on with these two branches. Thank you so much for the discussion. It would take me a *lot* of time to compare the two versions since my competence is Arrhenius/Thermodynamic theory, not computers and CFD software. For instance, I still struggle with the simplest gridding (tet unstruct) - and that limits the problems I can address. Also, I rely on repo-prebuilt codes... {blush} Enough of my complaining. The maintainer (ESI folks) has been very helpful with their code, which sits in my distro's repo.

It would be very useful to have more solver capability - I'm thinking of fully-coupled density-based Arrhenius chemical solvers, although I'm not absolutely sure full-coupling is necessary. I think density-based PISO is already available, but not for reacting flows.

BTW: what are NCC and AMI? (thus demonstrating my ignorance )

Best Regards,
PattiM

[Yann]

You're welcome!
If you are getting familiar with using OpenFOAM, I would advise to go for one branch and stick with it until you feel more comfortable. Just be careful to look at the documentation corresponding to the branch you are using. (if you use .com branch, the extended code guide is a good starting point: https://www.openfoam.com/documentati...doc/index.html)

Originally Posted by pattim

BTW: what are NCC and AMI? (thus demonstrating my ignorance )
PattiM

AMI (Arbitrary Mesh Interface) and NCC (Non-Conformal Coupling) are techniques used to interpolate data on non-conformal interfaces between patches. It can be used on moving meshes (like sliding mesh) or to couple together meshes with non conformal interfaces.

By the way, this has nothing to do with ignorance, CFD is a pretty huge topic, you learn about the things you need on the topic you are focusing on. When it comes to reacting flows, I'm the ignorant one!

Best regards,
Yann

[tomf]

Hi PattiM,

For a transonic PISO/PIMPLE reacting flow solver, please look at rhoReactingFoam.

If buoyancy is important there is rhoReactingBuoyantFoam.

For lower velocities one may want to use reactingFoam.

The code can be found online.

Best Regards,
Tom

[pattim]

Originally Posted by tomf

Hi PattiM,

For a transonic PISO/PIMPLE reacting flow solver, please look at rhoReactingFoam.

If buoyancy is important there is rhoReactingBuoyantFoam.

For lower velocities one may want to use reactingFoam.

The code can be found online.

Best Regards,
Tom

Since it's "rhoReactingFoam" I assume it's a density based solver, yes?

reactingFoam is what I'm currently using (at low speeds).

[pattim]

Originally Posted by Yann

You're welcome!
If you are getting familiar with using OpenFOAM, I would advise to go for one branch and stick with it until you feel more comfortable. Just be careful to look at the documentation corresponding to the branch you are using. (if you use .com branch, the extended code guide is a good starting point: https://www.openfoam.com/documentati...doc/index.html)

AMI (Arbitrary Mesh Interface) and NCC (Non-Conformal Coupling) are techniques used to interpolate data on non-conformal interfaces between patches. It can be used on moving meshes (like sliding mesh) or to couple together meshes with non conformal interfaces.

By the way, this has nothing to do with ignorance, CFD is a pretty huge topic, you learn about the things you need on the topic you are focusing on. When it comes to reacting flows, I'm the ignorant one!

Best regards,
Yann

I would hardly use the word ignorant!! The issues are solving the ODE's for Arrhenius reaction rates (interphase transport), which can vary over many orders of magnitude, and also species mass transport - for many, many species. Apparently these issues are ameliorated by coupling the species equations into the matrix solution of velocity, etc. There's little discussion of complex reacting flows in this case, so it's quite likely PISO could be good at Mach numbers (below, say, 3 - 5) with transonic flow. Also, it seems important to have a density-based solver for Mach structures. I know SIMPLE cannot handle these cases well.

Thanks again for your comments. Do you have any feel for density- vs pressure-based solvers in low speed compressible flows?

Oops! Apparently rhoReactingFoam is actually a pressure-linked solver - it just implements a different solution for certain thermodynamic variables.

[tomf]

Indeed there it is still pressure-linked.

I think the only density-based solver is

https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/compressible/rhoCentralFoam/rhoCentralFoam.C

. You would need to build the chemical/combustion part of the reactingFoam family against this solver for what you would like.

Maybe someone did this before, not sure.

[pattim]

Originally Posted by tomf

Indeed there it is still pressure-linked.

I think the only density-based solver is

https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/compressible/rhoCentralFoam/rhoCentralFoam.C

. You would need to build the chemical/combustion part of the reactingFoam family against this solver for what you would like.

Maybe someone did this before, not sure.

I'm not sure how I found it, but I was just looking at rhoReactingCentralFoam. I'm not sure it will be easy to deal with the "rho" part of this, though - that's the part which deals with thermodynamics - and I'm not sure whether it is required for the "Central" bit (the density-based solver).
https://github.com/duncanam/rhoReactingCentralFoam