Need a user-interface for dictionary

[gold2718]

In order to evaluate the completeness and utility of the dictionary, we need to be able to prototype how it will be used by models. At the very least, a data structure representing the dictionary should be created but even better would be to write a (read-only) API for how the dictionary can be accessed and queried and how necessary data will be retrieved. Some possible queries:

• List of sets
• List of entries (is a set name required?)
• List of properties for an entry (helps guard against version issues, e.g., if a property is added but not available in an older version of the dictionary or is not available for every constant).
• Value for a property (probably requires a set name and constant name).

[gold2718]

Another point to consider here is what the user-level interaction will be. Can the user specify a single "set" and get all the relevant constants? Will every set therefore include all usable constants (e.g., pi)? If not, how will usage of the CPCD be defined for any particular model run?

[gold2718]

I see from the CSC meeting notes (https://docs.google.com/document/d/1KKIOmhFOWWrle9mzHX5m3AOOR9N4RsBt1jPfI_CJ1no, unfortunately a restricted document) that the intent is to provide a standalone Fortran module for use by compliant models. Perhaps this issue should be closed in favor of an issue discussing the design and distribution of these Fortran modules?

[apcraig]

I think this is an important point. A user should be able to specify some arguments to a tool that produces the Fortran file and get a specific set or subset of constants. I would even go so far as to suggest the tools should be broader than that, and the YAML dictionary should NOT be hand edited. There should be tools to add entries, change entries, delete entries, list the current entries, and create a Fortran module. I understand this might be difficult and outside the scope of the project, but it would be useful. It would also separate the underlying format from the user, and yaml could later be changed to something else that was more efficient for this type of thing. I think yaml was chosen because it was relatively clean to edit/read, but I'm not convinced that tenable. By the time the file reaches 100 constants, 300 values, and 20 sets, it will still be extremely challenging to work with directly. I suspect we could come up with 100 constants very quickly.

[AndrewJConley]

We have a web interface to a database that we use to keep track of molecule properties. It (the underlying web service) produces output in a number of formats. It also supports heterogeneous representation of data: e.g., the data associated with dissociation of acids and bases in water has different parameters.

[AndrewJConley]

Furthermore, different parameterizations can lead to different meanings of "molecules". For example, the molecule, "BIGALK" could refer to molecules longer than 4 carbons or longer than 3 carbons. So it seems as if the molecular weight could be a chemistry-mechanism-specific value.

[AndrewJConley]

We are using JSON format to drive chemistry configurations. It is easily readable and editable, has parsers in every language I've ever heard of, and is the language of the web.

[gold2718]

@AndrewJConley : I would argue that BIGALK is not a physical constant and would not be a candidate for this dictionary. Also, given the level of funding for this project (is it even > $0?), I think a web interface is a bit much to bite off. However, I do support the suggestions of @apcraig that we provide a tool to search, view, and modify the dictionary to ensure consistency and correctness of the dictionary.

[AndrewJConley]

In chemistry we need flexibility to specify physical constants for all of our gas phase materials. These constants include molecular weight, index of refraction, henry's law coefficients, accomodation coefficients, etc. We are already using a web interface to a database to store these values and configure chemistry simulations. Given the fact that I think you are saying that all physical properties in this dictionary must be fundamental and must be universal removes the ability to store parameters for chemical processes (say wet deposition) in this dictionary. It also means that we will have to store data for (say molecular weight of ammonium sulfate) in two places: this dictionary and in a separate dictionary for chemistry processes (wet dep, dry dep, kinetics, aerosol-gas interactions, optical depths for condensed phase materials, etc.)

[gold2718]

I agree that this dictionary is not the place for everything which implies we need a way to distinguish data which should be included. The current dictionary prototype only includes sets of published physical constants. If there is a published constant set for chemical properties, it should be able to be included without interfering with other uses. In fact, I would argue that the chemistry database be partly created from the dictionary (e.g., including set IAPWS1995) with other data stored separately. With the appropriate user interface (recall that this issue is about the user interface), this should be easy to manage.

[AndrewJConley]

@gold2718 I'd be surprised if any of the constants in our database were inconsistent with published values. Especially given that the people populating the database are chemists and they keep track of such publications. Perhaps you are trying to simply provide a service that parameterizations can override? Are you planning to keep track of conflicting published data? We have a database of values, a user interface (web based), and a way to pass those values to the operating code. We could consider having a process to read the data from our dictionary and overwrite/extend values for your purposes if you'd like. Or, perhaps we ignore your dictionary and use our own? In order to support the range of chemistry, we need a flexible and tracked way of choosing values (see the index of refraction of volcanic (h2so4) aerosol in jpl database).

[gold2718]

@AndrewJConley, the whole point of this dictionary project is to provide a pathway for coupled model components to all be using the same, internally-consistent set of physical constants. To that end, it makes sense to me for the chemistry community to contribute to, and then use the dictionary where it makes sense, especially where other components will be using the same physical quantity (e.g., molar mass, index of refraction). This is part of a national push to enable (and then probably force) coupled models to use a consistent set of well-defined and documented physical constants.

[AndrewJConley]

I could imagine this being a resource that is available to parameterizations if they want it. But how would we maintain such a dictionary? Is this an attempt to replace the old CRC? How will it be kept up-to-date with current published results?

The development of parameterizations of chemistry has a broad range of needs that would interact with this resource:

• How to set the weights of XO3, XNO3 (tagged versions of O3 etc) that are prognosed along side the O3, NO3 etc.
• Does the molecular weight of "sulfate" refer to SO4--, H2SO4, or NH3SO4?
• Are atmospheric simulations sensitive to the precise values of H2O? I.E., are the isotopes included in this weight or not?
• Couldn't molecular weights simply be computed from the representative molecular formula?
• What will be required when we add the "left-foot-molecule" to our simulation?
• How do we extend this imformation to include all the properties required by parameterizations? E.g., Henry's Law data, diffusivity, surface activity, etc?
• How does a person overwrite this data to do an experment of interest?
• Why is data being defined as part of the model infrastructure, rather than a method to specify data?
• When a component of a condensed phase material (say the sulfate in each of the aerosol bins) refers to a particular material, how is the connection between this material's property (in this dictionary) associated with the particular data in the aerosol/cloud water?