Dear Richard, I agree that it would be great to have a default lineshape that can handle all the important parameters. But are we already there? My understanding was that we should move to a Hartmann-Tran lineshape as default. But does that allow line mixing?
Best wishes, Stefan > On 15. Sep 2017, at 12:04, Richard Larsson <[email protected]> wrote: > > Stefan, > > I will not add such a check. It is inconvenient to have for several reasons. > > First of all, you cannot combine lines that have line mixing data and don't > have line mixing data in a single tag even though all the calculations are > the same. Since, mostly, only the strongest lines have line mixing data > you'll need to make MOL-LM-AFGL-f_low-f_high and know the exact frequencies > of where the data has line mixing and not. You'll need two of those for the > 60 GHz O2 band since the outlier at 118 GHz has data but some lines in the > upper part of J don't, and they occupy the region around 65 GHz and above. > > It gets way worse for CO2 since the lines with line mixing data are mixed > lines without (no pun intended). I will go out on a limb and assume that > they don't know the exact lines that have and don't have line mixing data in > their catalog. Your suggestion of adding such a check will make the line > mixing code simply unusable for CO2. > > Secondly, the calculations work without line mixing data --- some lines > simply don't have the data and to ARTS this is all the same. If calculations > work, they should go through and produce output. It is up to the user to > ensure they have data they understand. That ARTSCAT-3 throws away > information should be seen as a bug and be fixed. > > Philosophically, I am against having the -LM- tag there at all since there is > either data or not for line mixing. The added time to calculations is small > --- it is not like for Zeeman where you don't want it if you don't need it. > If there is data, then the normal calculations are invalid and should be > stopped despite any tags if ARTS cannot perform them with the users consent. > This is not inline with current designs because we have the abs_lineshape > variable which the user need to use together with the correct catalog data > together with the -LM- tag to allow ARTS to compute line mixing... > (three-step verification is better than my bank and better than my Google > mail, so from a safety point of view this is really good design!) > > (As I said to you before, I am against having abs_lineshape in the workspace > to begin with because 1) I do not believe that ARTS users knows what this > does, and, most importantly, 2) the vital line shape information should be > dealt with by the catalog already. The present exceptions are cutoff and > normalizations, both of which are abused today anyways. Adding this to > ARTSCAT-5 and removing abs_lineshape would make a lot of calculations easier.) > > With hope, > //Richard > > 2017-09-15 18:24 GMT+09:00 Stefan Buehler <[email protected]>: > Hi Richard, > > ok, I understand the problem. I’ll discuss with Oliver. > > > (Alex ran into the former problem with the oxygen simulations yesterday. I > > guess he (or I) wanted to store O2 of LBLRTM to save reading speed but > > forgot to change the pseud-class index of the lines so all the line mixing > > data was missing upon reading). > > Should there not be a runtime error from the line mixing part if the line > mixing data is missing? Could you please add this? > > Best wishes, > > Stefan > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ arts_dev.mi mailing list [email protected] https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
