Hi Leo,
What you have encountered can be shortly summarized as rte_pos only
existing inside the Agenda you call. You don't have it at hand anywhere
else. rte_pos also does not represent what you think it does, it is simply
a radiative transfer equation position and it can be anywhere inside or
Hi Arts developers,
There was a significant update to the Arts development version merged today.
Please test this where you find it useful. Note that the new version uses
quite a bit more memory to compile as described in the README. Check your
system before you use all your cores (you might
t; Using the new behaviour I can either just use two calls to ReadARTSCAT to
> read directly into abs_lines (assuming this is actually the intended
> behaviour?), or reset temp_lines between the two calls. Without this then,
> as suspected, it adds the H2O lines twice.
>
>
>
>
Hi Stuart,
I would need some way to test this to give any real answers. For now I can
only ask questions.
It looks like you are somehow computing the 183 GHz line twice. This
should not happen easily. Have you somehow made a copy-paste error that
still retains a "complete" model in this
id this type of semi-duplication, or is it
> an acceptable thing to do?
>
>
>
> Stuart
>
>
>
> *From:* Richard Larsson
> *Sent:* 10 March 2022 15:50
> *To:* Fox, Stuart
> *Cc:* arts_dev.mi@lists.uni-hamburg.de
> *Subject:* Re: Another question related to complet
Hi Stuart,
The only two species (and this can be extended) that are passed to the
predefined models interface currently are O2 and H2O. (It is fairly easy
to add more molecules.)
To walk through the interface as a user:
In a call to propmat_clearskyAddPredefined in
Hi Stuart,
The easiest way to do this is perhaps to fix a few targets. You have to
edit two CMake files and change the path in your .cc file.
In the CMakeLists.txt under 3rdparty/Faddeeva/, you can add below the
"add_library":
target_include_directories(Faddeeva PUBLIC
>
> I also notice that the same VMRISO is in lots of the other complete O2 models
> (MPM87, MPM89 etc), so this isn’t restricted to Tretyakov-05
>
> Stuart
>
> From: Richard Larsson
> Sent: 22 October 2021 10:45
> To: Fox, Stuart
> Cc: arts_dev.mi@lists.uni-hambur
Hi Stuart,
I think you have found a bug. The isotopologue ratio is not fixed
anywhere, yet the VMRISO variable has been scaled down by its assumed
value. The comment for this value is simply false today, it must have
changed sometime without anyone noticing.
I think that VMRISO should be
The 2.5 way of absorption lookup table calculations is being redesigned.
For now you need to manually define the agendas as you do. Add lines will
be removed, at some point, from the xsec code. The reason it's deprecated
is that in normal calculations you should be putting the line calculations
Hi Patrick,
We can of course optimize the reading routine but there's no point in doing
that. The methods that read external catalogs should only ever be used
once per update of the external catalog, so it's fine if they are slow but
not too slow.
New memory is allocated for every absorption
Patrick,
I think I misunderstood you there.
There are two possible slowdowns there could be still. One is that you hit
some line count where you need to reallocate the array of lines because you
have too many. The other is that the search for placing the line in the
correct band is slow when
Hi,
It's expected to take a somewhat arbitrary time. It reads ASCII.
The start-up time is going to be large because of having to find the first
frequency, which means you have to parse the text nonetheless.
//Richard
On Sun, Sep 19, 2021, 20:19 Patrick Eriksson
wrote:
> Hi all,
>
> I have
Patrick,
I think it doesn't make sense to switch to this in ARTS. In fact, I don't
think it makes sense to use it at at all unless you want a fixed
low-altitude model.
It does make a lot of sense to provide some level of automation to take
care of the adjustments for fixed low-altitude models,
”.
>
>
>
> *From:* Fox, Stuart
> *Sent:* 10 June 2021 09:26
> *To:* Richard Larsson
> *Cc:* arts_dev.mi@lists.uni-hamburg.de
> *Subject:* RE: ARTS line absorption v2.3 vs v2.5
>
>
>
> Hi Richard,
>
>
>
> Thanks very much for your reply. I expect the dif
Hi Stuart,
All the differences between current 2.5 version and old version that I can
think of are:
The Doppler broadening is computed on shifted frequencies instead of on
unshifted frequencies. This should be more accurate as far as
I am concerned.
The normalization factor is computed on the
The current dev-branch also has this difference in it. I will try to
investigate tomorrow.
(There are even -250 K in one place of your results. So clearly something
weird is happening here.)
With hope,
//Richard
Den tors 6 maj 2021 kl 15:00 skrev Fox, Stuart :
> Dear ARTS developers,
>
>
>
>
Hi Stefan,
If we do something like this we have to start by removing abs_xsec_agenda.
There's no good way to mold the Zeeman effect into fitting with it.
I will inline the rest.
Den mån 1 feb. 2021 kl 17:29 skrev Stefan Buehler <
stefan.bueh...@uni-hamburg.de>:
> Hej Richard,
>
> to me the
Simon, Stefan,
It seems to me that this is a proposal of using a modern "void *"
list/vector with some strict interface. Have I misunderstood something
here? I mean you might implement it with virtual classes, std::variant, or
some other reinterpreting interface but that seems about it.
I am
Hi Stuart,
The dev-version of ARTS has full support of the workspace methods of
typhon. In fact, typhon.arts.workspace is simply pyarts.workspace with
some small modifications. So things should work as they have with typhon
just making that replacement in your imports. If you use other things
Dear ARTS developers,
The infrastructure for ARTS line-by-line data will change significantly
with an upcoming update to the development version of ARTS. Your
simulations will be broken before you adapt to the new infrastructure. I
will use this email to explain what updates are required to
Hi Simon,
I think that this is a good idea. I would go further and remove all of
constants.cc while you are at it. Or as much as possible.
Some notes:
You have misunderstood one thing. The Delta_nu_Cs variable is a properly
named snake_case variable that follows the naming convention of the
ks higher up, e.g.
> before entering interpolation. I assume we don't want checks on every
> level. So we need to be clear about at what level the checks shall be
> placed. If not, everybody will be lazy and hope that a check somewhere else
> catches the problem.
> >
> > In
Hi Patrick,
Den mån 25 mars 2019 kl 19:47 skrev Patrick Eriksson <
patrick.eriks...@chalmers.se>:
> Hi Richard,
>
> I can agree on that this is not always critical for efficiency as long
> as the check is a simple comparison. But some checks are much more
> demanding. For example, the
Hi Patrick,
Just some quick points.
Den sön 24 mars 2019 kl 10:29 skrev Patrick Eriksson <
patrick.eriks...@chalmers.se>:
> Hi Richard,
>
> A great initiative. How errors are thrown can for sure be improved. We
> are both lacking such checks (still to many cases where an assert shows
> up
Hi all,
I have kept running into problem with errors in ARTS produced by bad input
for OEM. Asserts are and not exceptions terminate the program in several
cases.
I just made a small update to turn several errors affecting Zeeman code
that before could yield assert-errors into try-catch to
Hi Stuart
ARTS 2-3-983 made significant changes in how the radiative transfer
calculations are performed. The idea of the changes was to average the
source level radiation rather than the layer itself. We believe the
changes can help speed up calculations of especially the Jacobian
Just short.
On Wed, Jul 4, 2018 at 20:06 Patrick Eriksson
wrote:
> Hi Stefan, Hi all,
>
> Thanks for the hint. Yes, we have not discussed these scattering
> solvers, but I did some googling about them just some weeks ago. I heard
> about these solvers at the ECMWF workshop, and got curios.
>
>
Hi Patrick,
Comments:
About the current setup, it is indeed a heritage from the past. I just
copied your setup. You had all unit conversion local.
I like the idea to allow more units but I think this should be handled at a
later stage than the iy-functions.
I have argued before that it would
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
e new version fixes the problem?
>
> Best wishes,
>
> Stefan
>
> > On 13. Oct 2017, at 17:56, Richard Larsson <ric.lars...@gmail.com>
> wrote:
> >
> > Hi Stuart,
> >
> > You are correct. The central frequency of the mirrored lines in arts
>
> once I’ve had a chance to get round to somehow installing cmake 3 on our
> systems so that I can actually compile anything newer…
>
>
>
> Cheers,
>
>
>
> Stuart
>
>
>
> *From:* Richard Larsson [mailto:ric.lars...@gmail.com]
> *Sent:* 13 October 2017 14
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
Hi all,
I would like to change so ARTSCAT-5 is the default format of lines when
reading from external files. Internal files can keep the old formats.
That is HITRAN and LBLRTM reading will be of ARTSCAT-5 type.
The reason to make the change is that I often run into problems of lost
data because
Hi Simon,
This is a very nice surprise in the morning, and I think it looks
excellent! It works for some simple cases I have been able to translate.
I found some cases that did not work but I am overall very impressed.
Thanks,
//Richard
Ps. The bugs I have encountered so far:
1) If I
use in the scattering data format could be used also
> in the propmat class.
>
> Some comments before starting the midsummer celebrations!
>
> Bye,
>
> Patrick
>
>
>
> On 2017-06-22 17:05, Richard Larsson wrote:
>
>> Hi all,
>>
>> I would l
Hi all,
I would like to propose switching to an internal representation of the
propagation matrix using a specially designed class, imaginatively named
"PropagationMatrix". Some background below. Inputs wanted!
With the help of Philippe Baron, I added a new matrix-exponent function
that is
37 matches
Mail list logo
