A Differentiable Reacting Flow Simulation Package in PyTorch

[jiweiqi]

Delete to avoid unintentional advertising of unrelated stuffs

[bryanwweber]

Thanks @jiweiqi! Sounds really cool. I'm glad you're able to take advantage of YAML, that's one of the reasons we wanted to introduce that format. If there are any changes that would make your work easier, feel free to propose them

[bryanwweber]

Hi @jiweiqi I wish we could standardize everything, but alas, we can't control that. There are also some good benefits of matching the input to the output, such as being able to directly compare and make sure the output is correct. What we might be able to do is provide a --convert-units option that puts everything into SI units (+ kmol) or something like that. But no promises about at timeframe 😄

[ischoegl]

@jiweiqi ... I believe some of the rationale you provide in DENG-MIT/reactorch/issues/5 falls short. As you write:

[...] Here I would like to share my own views. Cantera and Chemkin are great softwares which advanced the combustion modeling field in the past half century. In general, the usage of Cantera can be put into two categories, one is standalone modeling tool for zero-dimensional and one-dimensional reactors, the other one is a package for interpreting and computing the kinetics of mixture. For the former one, Cantera already do a great job, and it is object-oriented, which make me think that there is not much need to develop another package for this purpose. Although there are some new features from differential programming might advance those zero-D and one-D simulations, especially the sensitivity analysis and uncertainty quantification, which might be good motivations for ReacTorch.

Therefore, ReacTorch is more motivated for the second category. Here, the governing equations are written in users own software and ReacTorch is used to interpreting and computing the kinetics of the mixture, including the rates, thermodynamic and transport data. If the governing equations are also written in a differentiable way, then the entire model is differentiable. Then a lot of funs could start from here. It is also worthy to mention that those differential programing is usually associated with GPU, so that the entire model can be easily adapted to GPU. (This is also part of the reason why using ReacTorch for traditional modeling tasks in CPU could be much slower than Cantera and Chemkin). [...]

Reimplementing the 'second category' is de facto reimplementing the core of what Cantera intends to be (cantera means 'quarry' in spanish, and there really is the intent to provide 'buidling blocks' to the research community). The first category you mention are really examples for what can be done with Cantera (they are labeled as 'examples' for a reason). Without the second category, there is no first.

[ischoegl]

@jiweiqi ... I don’t think that needs of machine learning and more ‘traditional’ approaches are as different as you make them sound. If you are willing to dig a little deeper, all sides ultimately need the exact same tools that you decided aren’t worth pursuing within what you perceive as a ‘legacy’ framework. Your preference is certainly faster for short term goals, and I understand that the lab is new. Keeping it going for the long haul will be the real task.

[ischoegl]

To mention one of the aspects of your manuscript, Quasi-Steady-State-Assumptions (QSSA) aren’t specific to PINN (nor is the concept new, see work at UConn). To your point: if it’s not part of Cantera (which it isn’t at the moment), be part of the discussion and just pitch in. In return, you’ll be able to leverage others’ work in the long run.

[rwest]

I don't want to squash helpful discussion, but would like to make a reminder that we expect everyone to contribute to creating a positive environment, so even bystanders and others reading but not participating in the discussion feel like it's a welcoming place. Examples include:

• Being respectful of differing viewpoints and experiences
• Gracefully accepting constructive criticism
• Focusing on what is best for the community
• Showing empathy towards other community members
  Thanks!

[ischoegl]

@jiweiqi ... no problem, I do see that we have differing viewpoints as @rwest clearly recognized. I never intended to sound harsh myself (but am not a native speaker either). I hope you know that I believe your work has merit despite our disagreements. ReacTorch is of course a legitimate Cantera application.

[ischoegl]

@jiweiqi ... truly happy that you opened #82 - I was hoping to see a discussion along those lines. Regarding your comments about gaps in Cantera's Python API that you may have referenced to in #81, please let me know specifics. I believe there's a lot of value to make sure that all kinetic parameters are properly exposed, so a re-interpretation of a YAML input file should not be necessary within ReacTorch (the value proposition is not specific to ML, and the entire community will benefit). I know the code-base well, and exposing parameters available in C++ to the Python front end is not too difficult.

[ischoegl]

Not in a single call, but it's not difficult:

[([gas.n_atoms(sp, el) for sp in ['CH4', 'H2', 'H2O']], el)  for el in 'CHO']

[ischoegl]

For accessing Reaction kinetics parameters from Python, here are some examples (I realize that you may already be aware of this):

gas = ct.Solution('gri30.yaml')

rxn = gas.reaction(2) # Reaction 2 is an elementary reaction
rr = rxn.rate # Arrhenius class holding rate parameters
A, b, e = rr.pre_exponential_factor, rr.temperature_exponent, rr.activation_energy

rxn = gas.reaction(0) # Reaction 0 is a threebody reaction  
rxn.efficiencies # third-body-efficiencies
rr = rxn.rate # Arrhenius class holding rate parameters

rxn = gas.reaction(303) # Reaction 303 is a falloff reaction
rr = rxn.low_rate # Arrhenius class holding parameters
rr = rxn.high_rate # Arrhenius class holding parameters

I'm not certain that everything that is available in C++ is accessible from Python, but as I said it's relatively straightforward to add to the API.

[ischoegl]

That will work, just like gas.reaction(2).rate.pre_exponential_factor. I haven’t checked the docs, but yes, it’s not as obvious as other parts.

[speth]

The rate member of the ElementaryReaction class is documented as you can see here: https://cantera.org/documentation/docs-2.5/sphinx/html/cython/kinetics.html#elementaryreaction.

I might suggest that questions about how to use Cantera are a better fit for the Users' Group than threads attached to this or any other enhancement post.

[bryanwweber]

@jiweiqi For the same reasons as #89, I'm going to close this issue as well. If there are specific changes that are needed in Cantera, please update the issue. Thanks!