Does the "experimental" CLib have a way of setting unnormalized mass/mole fractions?

It does not have this at the moment. I anticipate that this will come up again in the context of MATLAB ... I am trying to keep some mode switches out of the interface implementation. Also, while I know that it is a needed function, I view it as a relatively odd implementation detail. If we can avoid exposing this in user-facing API's, I'd be in favor of alternatives.

I think we will need to provide this function. It's essential for users who want to use their own integrators.

I would remove this, since we never access it. (In .NET, the mere ownership of an object will not ensure it is cleaned up. That’s the job of the Garbage Collector, and for non-GC items like objects on the native Cantera side, we need to leverage the dispose pattern for deterministic release of the resources)

I'm a little uncomfortable deleting this object. The way the CLib Solution destructor is implemented, it will clean up associated ThermoPhase objects. I am not sufficiently familiar with the C# garbage collection to be sure that there aren't unintended side effects. Fwiw, here's the generated CLib destructor:

    int sol3_del(int handle)
    {
        // destructor
        try {
            auto obj = SolutionCabinet::at(handle);
            // remove all associated objects in reversed order
            if (obj->transport()) {
                int index = TransportCabinet::index(*(obj->transport()), handle);
                if (index >= 0) {
                    TransportCabinet::del(index);
                }
            }
            if (obj->kinetics()) {
                int index = KineticsCabinet::index(*(obj->kinetics()), handle);
                if (index >= 0) {
                    KineticsCabinet::del(index);
                }
            }
            if (obj->thermo()) {
                int index = ThermoPhaseCabinet::index(*(obj->thermo()), handle);
                if (index >= 0) {
                    ThermoPhaseCabinet::del(index);
                }
            }
            SolutionCabinet::del(handle);
            return 0;
        } catch (...) {
            return handleAllExceptions(-1, ERR);
        }
    }

Keep it for now, see comment below!

Until we add a proper Solution class, we only need to temporarily create the solution object on the native side (it also appears that it would be safe to destroy it once we extract the thermo object because it uses shared pointers). And to ensure the native solution object is released, we should dispose the handle by leveraging the using statement (also guaranteeing its release if an exception is thrown later in the constructor). Also, we need to call sol.EnsureValid() before using the handle to get the proper error message in case of a missing file.

(this assumes we remove the _sol field above)

See above: I'm not sufficiently familiar - this may introduce side effects that go beyond my wheelhouse.

Edit: As .NET would access the storage in CLib, I'm pretty certain that _sol needs to remain. The ThermoPhase handles will be gone as soon as the Solution object is destroyed.

@ischoegl I realized the handle handling is messed up in a number of ways. For example, right now when a ThermoPhaseHandle is disposed in .NET it calls thermo3_del(handle). But thermo3_del takes no arguments! I am surprised this doesn’t crash. Same problem for KineticsHandle and TransportHandle.

So I think we should merge this now, and I’ll create a follow-up to fix the these handles. In truth ThermoPhaseHandle, KineticsHandle, and TransportHandle shouldn’t be treated as such because they don’t identify an owned resource which can be closed independently. It will require some thinking on how the handle classes are scaffolded and which ones to scaffold at all, and how the wrapper classes are scaffolded.