General astrochemical code interface

[GijsVermarien]

Currently only KROME is available as a chemical code, and its interface is derived directly from CommonCodeInterface. Now I am interested in implementing the UCLCHEM gas-grain chemistry code (uclchem.github.io) into AMUSE, but there is no general interface for chemical codes. Do we want to implement a fifth type of interface as an additition to the AMUSE "quad-fecta", a general chemical code interface?

The codes would be relatively expert based, since the chemical networks need to be vetted for the astrophysical context, so we can think about how user friendly and battery included this class of codes should be in AMUSE.

Generally speaking most chemical codes need a few environmental parameters such as temperature, density, radiation fields and ionization rates. How would they best interface with the other types codes (gravity, hydro, radiative transport and stellar evolution)? In the end the chemical codes should just take chemical species of interest, and return them back to the user I assume. Questions are how we initialize species which the user does not wish to initialize and how chemical transport can be implemented between different grid points / particles in AMUSE, without becoming intractable.

A lot of the chemical codes are written in Fortran, so I suppose this could interface nicely with the AMUSE interface?

Personally I would be interested to develop a working example of a molecular cloud that is solved by UCLCHEM and a hydro code. Similar to: https://github.com/amusecode/amuse/blob/6ab25d3a8e78812ff76efe602dd64b4c6d6b6e68/examples/simple/molecular_cloud_chemistry.py

Am I missing things that are required for the development of such a feature?

[GijsVermarien]

List of nice-to-have chemical codes:

• Krome (already implemented)
• UCLCHEM
• Chimes

[rieder]

Comment from @mmaclow on Slack:
"The general complication I see is that the chemistry code needs to somehow be coupled to the hydrocode timestep to avoid large composition changes happening in single timesteps."
I agree - and this is of course an issue we're seeing more often, e.g. with radiative transfer codes.
For a fixed timestep code it could be done, there would just be a lot of communication.
For individual timestep codes, the step visible to AMUSE is usually just the global one, which would be too long. Here, we might be able to use/repurpose the stopping conditions interface. This requires more thinking/discussing.