Reformatting MOM_input.yaml

[alperaltuntas]

I am debating whether to apply to following changes in MOM_input.yaml

• Remove datatype and units attributes, since they aren't used at all when MOM_input file gets generated.
• Remove the description attributes from MOM_input.yaml and instead specify them in another (yaml?) file instead. This should greatly shorten MOM_input.yaml. This would introduce the danger of adding a parameter in MOM_input.yaml and not adding its description in the other file, but we can easily add a check for it in the github CI tests.

Any objections? Further suggestions? @mnlevy1981 @gustavo-marques

[gustavo-marques]

I am in favor of shortening MOM_input.yaml so no objections. Would it be possible to create a script that writes the description attributes automatically (by searching MOM6 dev/ncar)?

[alperaltuntas]

Sounds like a great alternative! Looks like it is all in Python, which is another big plus. As for what we are trying to accomplish, we are looking to extract the descriptions of runtime parameters from the MOM6 code, i.e., look for all get_param calls and generate a dictionary of varname:desc arguments. Would flint be able to accomplish that?

| Also, this is a bit off-topic, but FMS is switching to YAML-based configuration files (initially diag_table but eventually everything I expect), and has nudged MOM6 to consider the option.

Happy to hear that!

[marshallward]

Not out of the box, but I think the information is all there to do it. I think one could put together a user script which does it. Let me give it a try and see what is possible.

(Forgot to mention: The MOM5 group in Australia was using a much older version of flint for this exact same purpose!)

[marshallward]

Potential script to scrape get_param calls: https://gist.github.com/marshallward/33d96a35b6fc4318f36f1b6b63c35ed2

Potential output: https://gist.github.com/marshallward/d52199b403cd2dbe3d0ff7d330ee16fb

Was not as easy as I had hoped for a couple of reasons:

• The parser doesn't classify the expression, so args had to be manually gathered.
• Many of the parameter names and variables are themselves expressions, and I don't think there's an easy way to know how to evaluate them.

First issue is more of an inconvenience, and we could add some features to flint to help out. But the second one looks somewhat problematic if your goal is to list every possible parameter.

(I'm guessing MOM_parameter_doc.all is not an option here due to the conditional logging of some parameters.)

We can talk more about it if you think there's a potential solution here, though.

[alperaltuntas]

Thanks, @marshallward. The gist.github.com links don't work for me, I get 500 error code. Yeah, the second issue does sound challenging. An AST-based approach could help evaluate some, but probably not all of them. I think any substantial effort on this is not worth it, and our current manual approach is not much of a hard work anyways...

[alperaltuntas]

The links are working for me now, it was probably a temporary issue.

[mnlevy1981]

I'm okay with splitting the two, and I like the idea of verifying every parameter has a description during CI. could you add the check to yaml_to_json.py? I think that would be an easy way to add it to the CI while also ensuring developers run it as part of the normal development cycle.

[alperaltuntas]

could you add the check to yaml_to_json.py

Sounds good!