Use of C bindings.

[Bloody-Ari]

First of all, sorry if this is off-topic or non sense, but I am trying to build a C program that uses CEA to solve a Rocket, expanding it a bit with C (ie. providing information like how much propellant would be actually needed). I've done some preliminary work using Excel and extracting data using cearun and Python so I know it's doable. It'd basically be a front end tho.

I could follow the python examples but I have a few questions regarding a C implementation:

1. Is the cea_init() (from cea.h) bind memory safe? I haven't found a function that stops it, which leads me to believe that the next snippet is correct. Is that assumption correct?

int main(){`
  cea_string species[] = {"AL", "HCL", "H2O"};
  cea_int nspecies = 3;
  cea_mixture *mixture;

  cea_init();

  cea_mixture_create(mixture, nspecies, species);
  cea_mixture_destroy(mixture);

  return 0;
}

2. Is there any documentation about using the c bindings directly? What about using Fortran directly? The docs in the repo only seem to encompass python.
3. Is CEA "supported" or "expected" for this kind of use or should I turn to Python?
4. Would I have a better shot at this using file inputs with ReactantInput type and all that? (Like the stuff here)
5. Are there any similar projects? I've found combustion toolbox which is a very nice project but not exactly what I am looking for (and it's written in Matlab).

[markleader]

This is definitely on-topic.

Yes, using CEA as the computational core behind a C-based rocket front end is a reasonable thing to do. Python is not required here, it is just one of the available interfaces.

On cea_init(): in the current implementation it performs process-wide initialization of the global thermo/transport databases. It is not a per-object allocation, and there is no public cea_finalize()/shutdown function. The intended lifecycle is basically: call cea_init() once, create/destroy mixtures/solvers/solutions as needed, and let the process keep the global database state for its lifetime. So for a normal executable that is fine, but it is not a balanced init/shutdown API. Also, initialization is explicitly not thread-safe.

Your snippet is close, but the handle declaration is off. cea_mixture is already an opaque handle type, so the pattern is:

int main(void) {
  cea_string species[] = {"AL", "HCL", "H2O"};
  cea_mixture mixture;

  cea_init();
  cea_mixture_create(&mixture, 3, species);
  cea_mixture_destroy(&mixture);

  return 0;
}

In real code, I would also check every cea_err return value.

On documentation:

There is a C API reference in docs/source/interfaces/c_api.rst.
The public C surface is in source/bind/c/cea.h.
There are C examples under source/bind/c/samples/.
There is also a Fortran API reference in docs/source/interfaces/fortran_api.rst.
So the C and Fortran interfaces are documented, but today they are more reference-oriented than tutorial-oriented. The worked examples in the docs are mostly Python.

On whether CEA is “supported” for this use case: yes. Python is a convenience layer, not the only intended way to drive the library. If your surrounding application is already in C, using the C binding directly is a reasonable approach.

On ReactantInput vs file inputs: if you are writing a programmatic front end, I would prefer the direct C API over generating legacy input files. Use cea_reactant_input when you need custom reactants or custom elemental composition. If you are only using species already present in the thermo database, the simpler mixture constructors are probably enough. The legacy text/file interface is more useful when you specifically want CEA2-style deck compatibility, but this approach will be much slower due to file I/O.

For rocket-specific work, the closest examples in-tree are the C RP-1311 rocket samples (rp1311_example8.c and rp1311_example9.c). There is also a C sample using input reactants (rp1311_example5.c). Those are probably the best starting points for a C implementation.

On similar projects: within this repo, the closest references are those C samples rather than a full standalone C front end. I’m not aware of a canonical larger C application in-tree built on top of the binding.

If you want to share a rough sketch of the rocket workflow you want to drive from C, I can probably point you to the closest API path or sample.

[Bloody-Ari]

Thank you a ton, sorry I haven't seen the docs and samples before and took your time, they are exactly what I was searching for! And thanks a lot for the clarifications.

[markleader]

You're good! Glad that helped.