Ok, then 'Mirrored Lorentz' is not a good replacement since it works
differently.  This will also be difficult to consider in any new
implementation.  I thought the policy was to leave such optimizations up to
the user...

The new system I suggest has to remove the lineshapes of today and replace
them with 'best-match' alternatives.  Numerically, the difference should be
nil to very small.  Of course, in the end you should be able to manipulate
individual lines to say what lineshape they should be using, but that will
then have to be stored on a line-by-line basis and not on a
speciestag-by-speciestag basis.  Functions like
SetAllLinesOutsideTheFrequencyGridToUseLorentzLineShape  and
SetAllLinesOfSpeciesTagToUseACutOffOfF(tag="H2O", F=750e9) should be
possible (but sometimes risky choices), and will allow similar controlfile
manipulation of the lineshapes as the abs_lineshapeDefine function.

Computationally, the speed would vary quite a lot.  I have the files that I made to work with the linemixing code.  It
is about as fast as the normal solutions today --- it is faster if you
deactivate some IEEE-code and tell the compiler to properly optimize for
your system --- but things like VoigtKuntz6 is not working because it only
produces half a lineshape today.

(VoigtKuntz6 could be made to work, though it will be much slower than the
present implementation since the current setup is optimized for it to be
fast --- the other lineshapes are slower today because they have to work
around the VoigtKuntz6-imposed limitations.)

I will try to make an abs_xsec_per_speciesAddLines2 function sometime later
this week or next using the other setup.  This will not be feature-complete
by then but it will be better to have this discussion when some code


2017-10-16 10:56 GMT+02:00 Stefan Buehler <>:

> Dear Richard,
> > Ps. The cutoff is determined based on the negative frequency and not on
> the frequency of the line.  Not sure if that is intentional or not, since I
> still have not read the papers on why the cutoff exists.  This is not a big
> numerical issue but at most a potential mismatch in theory.
> This is intentional, since in this way mirror lines that are far away are
> optimised away.
> I am fine with moving to a new system altogether, as you propose, but we
> have to make sure the program keeps working. We cannot first remove the
> working lineshapes, and then later introduce new ones.
> Best wishes,
> Stefan
arts_dev.mi mailing list

Reply via email to