Facilitate porting of rate constants to MICM

[mattldawson]

MUSICA should make it easy to inject photolysis rate constants from TUV-x or another calculator into MICM. Some type of mapping.

Acceptance Criteria

• A test that demonstrates the calculation of photolysis rate constants in TUV-x, copying into MICM rate constant data structure, and solving with MICM is included in the test suite
• Mapping is automated when the "MUSICA name" in a MICM photolysis reaction matches the name given to a TUV-x photolysis reaction
• Users can configure custom mapping when the names in MICM and TUV-x don't match, and can include scaling factors that will be applied to rate constants before copying into MICM

Ideas

• A JSON/YAML file that specifies the mapping configuration could be used:

"map" : {
  "auto-match" : true,
  "custom mapping" : [
    {
      "source name" : "foo",
      "destination name": "jfoo"
    },
    {
      "source name" : "bar",
      "destination name" : "jbaz",
      "scaling factor" : 0.75
    }
  ]
}

• Users could do something like:

  // create MICM, TUV-x
  Error error;
  MICM* micm = CreateMicm(config_path, &error);
  TUVX* tuvx = CreateTuvx(config_path, &error);

  size_t n_micm_rxns;
  Mapping* micm_rxns = GetUserDefinedReactionRatesOrdering(micm, &n_micm_rxns, &error);
  double custom_rate_constants = new double[n_micm_rxns];

  size_t n_tuvx_rxns;
  Mapping* tuvx_rxns = GetPhotolysisReactionLabels(tuvx, &n_tuvx_rxns, &error);
  double tuvx_photo_rates = new double[n_tuvx_rxns];

  IndexMapping* tuvx_to_micm = CreateIndexMap(map_config_path, tuvx_rxns, n_tuvx_rxns, micm_rxns, n_micm_rxns);

  TuvxCalculate(tuvx, tuvx_photo_rates);
  ApplyIndexMap(tuvx_to_micm, tuvx_photo_rates, custom_rate_constants);
  MicmSolve(micm, ..., custom_rate_constants, ...);

• Alternatively, force TUVx to publish named photolysis rates. The musica names of photolysis rates inside of the mechanism configuration must match one of these. Then, at runtime, tuvx would take in a list of names that it would know it needs to calculate. Defaults for all other data attributes would be used, but still be allowed to be overriden. This removes the need for a TUVx configuration and a mapping configuration, but means we have to choose sensible defaults

[boulderdaze]

From the description,
"MUSICA name" in a MICM photolysis reaction matches the name given to a TUV-x photolysis reaction.
Would source name be for musica name and destination name for tuvx? Are they always going to be different?

      "source name" : "foo",
      "destination name": "jfoo"

The example APIs look good to me, but the alternative idea sounds more efficient by skipping mapping during solving.
Could you explain more about this ... but means we have to choose sensible defaults? Are they given from tuvx configuration?

[K20shores]

@boulderdaze I'm actually not sure if we need defaults. Initially, I was thinking that would be profiles and grids, but those are all things that we've added anyways and will come from the model. The defaults, I suppose, would be the cross sections and quantum yields for a particular rate, but those can be fixed anyways for a particular rate.

Also, musica name is an allowed attribute on any reaction in our mechanisms. Destination name would be a name we give to a rate in tuvx, but it's not a required field if I remember correctly. They could and likely will be different, but could be the same. Just depends on who made them (usually us, i'm betting)

[K20shores]

It may be of use to do what was done in CAM