Stefan, 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 lineshapesdata.cc/h 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 exists. //Richard 2017-10-16 10:56 GMT+02:00 Stefan Buehler <stefan.bueh...@uni-hamburg.de>: > 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 arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
