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
o
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 ne
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 setup?
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
m_predefined_absorption_model
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 ${CMAKE_CURRENT_SOURCE_DI
>
> 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 change
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
i
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 lin
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 ther
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 no
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, b
anual”.
>
>
>
> *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 th
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 u
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 inte
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 no
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 f
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 cont
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
In
ed that you wanted the checks as far down as possible. But
> the last email seems to indicate that you also want checks 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
>
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 altitude
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 instea
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 throw
Hi,
(This is mainly a question to Simon and Patrick but the dev-list exists so
I am using it.)
I have been trying out the retrievalAdd* functions for the systems we have
in Gottingen. One of the most difficult bit is to figure out is how to
complete the retrieval setups without running loops aro
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
significantly
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.
>
> Y
Ok,
So those tests should have been commented out during this 'intermission'
but were forgot. I understand.
//Richard
2018-02-08 2:36 GMT+09:00 Jana Mendrok :
> Hej Richard,
>
> thanks for the note.
>
> Ps. Three controlfiles fail the slow test currently:
>> 8 - arts.slow.doc.
Hi All,
Bad news. I just broke your controlfiles if you update to the latest
version. Sorry about that.
Good news. ARTS can now compute radiative transfer directly from
population level distributions. This was made possible due to contribution
from Takayoshi Yamada of his NLTE code to typhon.
Hi Patrick,
In principle I agree that that would be the cleanest solution. I did
> consider this but ruled it out due to practical issues. Maybe I should have
> mentioned that in the first email, but was afraid that it would cause
> distraction from the main topics.
>
> I think the unit conversion
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
> Best wishes,
>
> Stefan
>
> > On 13. Oct 2017, at 17:56, Richard Larsson
> wrote:
> >
> > Hi Stuart,
> >
> > You are correct. The central frequency of the mirrored lines in arts
> are just set to be negative, letting all the other calculati
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:01
> *To:* Fox, Stuart
> *
Stuart,
I am also seeing the problem but I have no time to investigate in detail.
As a temporary solution, there exists another lineshape called "Mirrored
Lorentz" that you can use. Testing your controlfile with it instead, the
results are more reasonable. Simply change your
abs_lines_per_speci
ere? 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
> wrote:
> >
> > Stefan,
> >
> > I will not add
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
Stefan,
ARTSCAT-3 throws away line mixing data, which is kept in ARTSCAT-5. It
also throws away the Einstein coefficient and the statistical weights of
the lines. I am unsure if it even parses quantum numbers. All of these
things are needed in advanced calculations and provided for in HITRAN.
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 understand
a 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 like to propose switching to a
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 abou
y.
>
> I'm happy (and usually try) to fix warnings if I see them. However,
> currently I don't have access to a 16.10 installation. Which gcc version is
> Ubuntu using now? Maybe the version is available in MacPorts, then I'm
> happy to have a look at them.
>
&
Hello all,
The latest gcc iteration on Ubuntu is complaining on a level that it did
not do before when compiling ARTS. It lists indentation warnings,
conversion warnings, guarding warnings, and others. This floods the output
and hides real errors for me.
I am somewhat confused by all these addi
arts -d abs_lineshapeDefine
> >
> > and not
> >
> > arts -d abs_lineshape
> >
> > ? At least I tried the last version first when updating my memory.
> >
> > Bye,
> >
> > Patrick
> >
> >
> >
> >> /Stefan
> >>
&
Hello Ole,
Yeah, it is because we moved a lot of the partial derivatives to lower
levels. You are asking for a partial derivative of something that requires
knowing the partial derivative of the line shape with respect to your
variable. This is trivial if the function returns the phase shift but
48 matches
Mail list logo