Add pyarts metmm

[obobryshev]

Hi Oliver,

I followed the "How to contribute guidelines". This is a fully working py-metmm setup using the pyarts. All sensors setups run without problems.

Several issues that I know of:

1. I had to switch on robust=1 in ybatchCalc, because I got the following run-time error for Garand atmospheres index: 16,17 and 21

Run-time error in method: atmfields_checkedCalc
There are bad partition functions in your setup.
Minimum temperature for defined partition functions is: 150 K.
Maximum temperature for defined partition functions is: 300 K
There is a t_field entry of 314.81 K.

2. Current origin/master branch results in the deltas of -30 to 60K compared with "ybatchREFERENCE.xml". Also, the TestMetMM in controlfiles/instruments/metmm fails with similarly big differences.

• Also "O2-TRE05" full model gives -30 to 60K difference to the "ybatchREFERENCE.xml".
• Check of "amsub" setup with reference only works for branches remotes/origin/v2.4.x and remotes/origin/before-newlinerecord.

3. One note to the "How to commit" documentation. I didn't understand the section Update your working copy, and what the upstream and rebase actually do, e.g. in this code git pull --rebase upstream master.

4. I have a separate github repository for py-metmm setup. I created it if I need to imporove the metmm code a bit more.
   https://github.com/obobryshev/py_metmm

5. MetMM setup relies on the extract of HITRAN2012 with the changed line parameters for WV line at 183.31 GHz: controlfiles/instruments/metmm/abs_lines_metmm.xml.gz Both metmm versions rely on this file. Is it ok to rely on this file for both versions for now? In the end I plan to read the HITRAN catalogue and change this one line parameters on-the-fly using the function abs_linesReplaceWithLines. This is an open todo.

Kind regards,
Alex

[simonpf]

Hi Alex,

Just to understand the background, what is the motivation for moving metmm from ARTS to Python?
And what is the difference between the Python methods and just executing the MetMM controlfiles
on the workspace?

Also is the plan for this to replace the native ARTS implementation? Because I reckon some people
may be very much in favor of this.

Cheers,

Simon

[obobryshev]

Hi Simon,

this is a purposefully redundant system, as far as I understand, at least for now, both options will be available for the users. There must be no difference between the Python methods and MetMM controlfiles.

I use the python implementation in sensitivity studies for spectroscopic parameters of water vapor and oxygen models. The workflow is much easier when using the python-based setup. Hopefully people can use this setup in their research as well.

In the future (if needed), I'll prepare unified setups for other sensors (e.g. NIR and IR, geostationary?) in python as well.

Cheers,
Alex

[olemke]

Hi Alex,

The system is not meant to be redundant. We want to avoid maintaining a controlfile and a Python script for the same example. There are two cases:

1. The example/testcase can be fully implemented in the ARTS controlfile language.
2. The example/testcase is more complex and uses features that require the use of Python.

For 1, the testcase should be written as an ARTS control file. For 2, it can be written as a Python script.

Maintaining all controlfiles in two places would be too much work. It's also not necessary because there is a mechanism in the build process of ARTS that converts all controlfiles to Python scripts and verifies that both versions run correctly.