Air density should be passed to MICM solve function

[mattldawson]

The air density [mol m-3] should be passed to the musica.micm_solve() function, similar to temperature and pressure. The calculation of air density should be based on the ideal gas law.

Blocked by NCAR/musica#157

Acceptance Criteria

• Air density based on the specified temperature and pressure using the ideal gas law is passed to the musica.micm_solve() function at each time step

Ideas

• Use the same algorithm as for calculating [M] to get the air density:

  music-box/src/acom_music_box/music_box.py

  Lines 513 to 517 in 589377b

  	if 'M' in species_constant_ordering:
  	BOLTZMANN_CONSTANT = 1.380649e-23
  	AVOGADRO_CONSTANT = 6.02214076e23;
  	GAS_CONSTANT = BOLTZMANN_CONSTANT * AVOGADRO_CONSTANT
  	ordered_concentrations[species_constant_ordering['M']] = curr_conditions.pressure / (GAS_CONSTANT * curr_conditions.temperature)

• Instead of calculating [M], change it's "tracer type" to "THIRD_BODY_SPECIES" in the configuration data, and let MICM set its value based on the specified air density. See here: https://github.com/NCAR/micm/blob/854ca2db7ea2a70cb72541a2436300c327e51578/test/unit/unit_configs/third_body/species.json#L7-L11

[carl-drews]

Instead of calculating [M], change it's "tracer type" to "THIRD_BODY_SPECIES" in the configuration data, and let MICM set its value based on the specified air density. <

The "tracer type" of the camp-data? As read from species.json?

[mattldawson]

Instead of calculating [M], change it's "tracer type" to "THIRD_BODY_SPECIES" in the configuration data, and let MICM set its value based on the specified air density. <

The "tracer type" of the camp-data? As read from species.json?

Yes. My suggestion would be to have the python code add a species to the species.json file called M with a tracer type: THIRD_BODY. If a species M exists in already in species.json, I think we should return an error that says that a species named M is reserved for third-body species.

The species M (because it is a THIRD_BODY tracer type) will not appear in the species_ordering list because it is parameterized.

[carl-drews]

Thank you @mattldawson. This approach is reminiscent of TUV-x. I will proceed. :-)

[carl-drews]

I tried adding the M to species.json directly as a first step:

        {
            "name": "irr__2a109b21-bb24-41ae-8f06-7485fd36f1a7",
            "type": "CHEM_SPEC"
        },
	**{
            "name": "M",
            "tracer type": "THIRD_BODY"
        }**

I get this error:
File "C:\Users\drews\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.12_qbz5n2kfra8p0\LocalCache\local-packages\Python312\site-packages\acom_music_box\music_box.py", line 420, in create_solver
self.solver = musica.create_solver(path_to_config)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Error creating solver: object: {"name":"M","tracer type":"THIRD_BODY"}; type: type: Object type not found

Does musica have to know about the new "tracer type" here?

[carl-drews]

I get farther along when I add the type:
{
"name": "M",
"type": "CHEM_SPEC",
"tracer type": "THIRD_BODY"
}

[carl-drews]

I have not discovered a way to pass in the M species to musica.micm_solve() as described above. Even after bypassing the Key error while setting ordered_concentrations (line 703 of music_box.py), the execution thread goes into micm_solve() and terminates the script without further information:

            logger.info("Going into micm_solve()...")
            musica.micm_solve(self.solver, self.box_model_options.chem_step_time,
                curr_conditions.temperature, curr_conditions.pressure, air_density,
                ordered_concentrations, ordered_rate_constants)
            logger.info("...Coming out of micm_solve()")

[carl-drews]

musica.micm_solve() returns without known errors if I create the M species in Python as the final step before solving:

            mSpecies = Species(name="M")
            mSpecies.tracer_type = "THIRD_BODY_SPECIES"
            self.species_list.species.append(mSpecies)

However, there is no change in M after micm_solve(), so I must still be missing something.
INFO:acom_music_box.music_box:M species 34567 {'name': 'M', 'absolute_tolerance': None, 'phase': None, 'molecular_weight': None, 'density': None, 'tracer_type': 'THIRD_BODY_SPECIES'}

[K20shores]

So I guess there are at least two issues. One is that we aren't seeing any useful error message, another is that we can't proceed with solving. I will try to send out a release today or tomorrow that will hopefully solve the error message problem. Then maybe that will help us move this further along

[K20shores]

For reference, we have a test of chapman using the python wrapper in musica which reads this configuration and there M is not marked as a third body species. So it seems we need to update our test case in musica. I will do that with the release

[K20shores]

We have addressed the underlying issue in micm. Once this is merged I'll get a new release (0.7.1) of musica out which should make this fix available here

[carl-drews]

With this configuration of M in music-box/tests/configs/analytical_config/camp_data/species.json:
{
"name": "M",
"type": "CHEM_SPEC",
"tracer type": "CONSTANT",
"__description": "third-body species"
},

musica.micm_solve() succeeds and passes back a solution. mySolution.csv has a column CONC.M, but that column is all zeros. Isn't MICM supposed to set the value of M based on the air_density parameter? Calculated at 44.68980861228497?

[K20shores]

@carl-drews my PR in #178 uses musica 0.7.3 with THIRD_BODY successfully, perhaps you still have an old version of musica?

[carl-drews]

My version of musica is now fixed at 0.7.3 for music-box after fixing the pyproject.toml file.

I can run chapman_config successfully with species.json including:
{
"name": "M",
"type": "CHEM_SPEC",
"tracer type": "THIRD_BODY"
},

But my solution has CONC.M = 0.0 for all time steps. Isn't MICM supposed to set that to the air density?

[K20shores]

It is supposed to set the air density. I think you can remove any setting of the M concentration

[K20shores]

I believe I had to do that in #178, though I don't really remember now

[carl-drews]

This issue is addressed in Pull Request 186: #186

[carl-drews]

Resolved and merged with main branch.