Feature/fictive species

[Acoudray1]

Changes proposed in this pull request

• Additionnal transport equations are possible (known as fictive species in AVBP)
• Possibilities to change the boundary conditions as well as the source term
• An example is provided in samples/python/AVBP/fictive_species.py

If applicable, fill in the issue number this pull request is fixing

Closes #

If applicable, provide an example illustrating new features this pull request is introducing

Checklist

• [X ] The pull request includes a clear description of this code change
• Commit messages have short titles and reference relevant issues
• [NOPE] Build passes (scons build & scons test) and unit tests address code coverage
• Style & formatting of contributed code follows contributing guidelines
• [NOPE] The pull request is ready for review

[bryanwweber]

Hi, thanks for sending this pull request! It would certainly be an interesting feature to add. I looked very briefly at some of the changes and many of them seem unrelated to the new feature, for example the new packaging workflow, some of the documentation changes, changing refine to a string, etc. Can you simplify the changes here to the bare minimum needed for the feature itself? Thank you!

[ischoegl]

@Acoudray1 ... welcome! I likewise appreciate this pull request. Realizing that this is still in 'draft' mode, I did notice a rather large line count. As much of this appears to be caused by the inclusion of mechanism files, I wanted to point out that we started to move mechanisms to the dedicated cantera-example-data repository; we also no longer distribute cti files. Adding those mechanisms can be accomplished very quickly there.

Beyond, I second what @bryanwweber mentioned - please avoid introducing code unrelated to the PR topic. As much as I want to see features developed by CERFACS consolidated, we may have to accomplish this one feature at a time. Regarding changes to the Cantera API, we follow a fairly robust deprecation cycle for anything that isn't marked as 'experimental'. I.e., changes of method names or argument types need to be introduced without breaking user code. Finally, I noticed a change to the legacy CLib (in ctonedim.h): please note that this interface is slated for removal in the near future (i.e., after the release of Cantera 3.2, which is imminent); the CLib is replaced by generated code.

[Acoudray1]

Hello everyone,
I made a mistake as I wanted to make a merge request in our own branch that's why you are seeing all these changes while we are not ready to make a proper merge of all our features ... I'm too used to private repository !

Thank you for all your inputs that are very valuable :)

Should I close this merge request to avoid polluting ?

Thank you !

[ischoegl]

@Acoudray1 ... I'll leave this up to you. From my perspective, I'd welcome seeing CERFACS features be added to the main Cantera branch, which should reduce the maintenance effort on the CERFACS fork significantly.

[Acoudray1]

I definitely aggree with you. For now I leave this draft as is and I will discuss with the guy in charge of cantera at cerfacs, that way we'll do things nicely, notably separating features !
Thank you for your inputs and sorry for the mess.