Diátaxis

[Stefan Buehler via arts_dev.mi]

Dear all,

here is the link to the documentation philosophy that was pointed out to me by 
Robert Pincus: https://diataxis.fr

I quite like it, especially, that it does not try to impose a certain technical 
system or rigid structure, but rather helps one to think about the problem.

/Stefan

smime.p7s
Description: S/MIME digital signature

Re: Kristineberg ARTS workshop 2024, register now

[Stefan Buehler]

Dear radiation-enthusiasts,

we have already received a good number of registrations, but still have some 
free places left. So, we decided to extend the registration deadline by two 
weeks, to March 14. The plan is that on March 15 we convenors will sit together 
and draft the program, based on the contributions that we have received by 
then. Here is the registration link again: 
https://www.mi.uni-hamburg.de/arts2024 .

Best wishes,

Stefan

On 30 Jan 2024, at 10:11, Stefan Buehler wrote:

> Dear all,
>
> summer 2024 is drawing closer, and so is the highlight of this summer, the 
> ARTS radiative transfer workshop at Kristineberg research station, on the 
> Swedish west coast.
>
> The workshop will be on June 4-7, 2024 (from noon to noon). The target 
> audience are users and developers of the atmospheric radiative transfer 
> simulator ARTS, and also anyone interested in spectroscopy or radiation that 
> can give us new impulses.
>
> Anticipated topics are:
> Gas absorption
> Scattering
> Surface interaction
> The shortwave side of things (since this is new in ARTS)
> ARTS applications
> New sensors
>
> We anticipate that there will be dedicated talks sessions on these topics, 
> plus posters, and also space for informal discussion and practical help with 
> ARTS. Please indicate your contribution(s) with the registration, we will 
> then compile an explicit agenda.
>
> Some practicalities:
>
> There will be a free bus transfer from Göteborg on June 4 at 10:00, and back 
> to Göteborg on June 7, arriving approximately at 15:00. The workshop fee is 
> around 460€ all inclusive if you stay at the research station, and 
> approximately 280€ (including lunch and dinner) if you stay at one of the 
> nearby hotels (plus the cost of the hotel). You pay the fee directly to the 
> research station's staff (only card payment). The number of participants is 
> limited to 50, due to the size of the bus, and the number of beds at the 
> research station itself is limited to 45, so register soon if you want to 
> take part!
>
> Note also that there are only a few single rooms at the research station, so 
> most people staying on-site will have to share a double room. The 
> registration form allows you to indicate if room sharing is ok for you or not.
>
> Registration: https://www.mi.uni-hamburg.de/arts2024
>
> Registration deadline: February 29
>
> Some useful links:
>
> Kristineberg marine research station:
> https://www.gu.se/en/kristineberg
>
> Hotels within walking distance (Gullmarsstrand, Slipens):
> https://gullmarsstrand.se/en/hotel/
> https://www.slipenshotell.se/ (link seems not to work for some people, 
> alternative: https://www.booking.com/Share-8DAo0f )
>
> Hoping to meet you in June!
>
> Patrick and Stefan

smime.p7s
Description: S/MIME digital signature

MSc Atmospheric Science at Universitaet Hamburg - apply now

[Stefan Buehler]

Dear all,

I would be very grateful if you could help spread this information. Our new 
international master program is recruiting its second round of students now. 
Amongst other things, it includes an advanced course on radiation and climate 
that I am teaching, and that uses ARTS for the exercises. There is also planned 
to be an ARTS-based remote sensing course taught by Manfred Brath.

Cheers,

Stefan

Forwarded message:

> From: Felix Ament 
> To: mpi...@mailman.rrz.uni-hamburg.de
> Subject: [Members.cen] [mpicen] MSc Atmospheric Science at Universitaet 
> Hamburg - apply now
> Date: Mon, 26 Feb 2024 10:31:57 +0100
>
> Dear all,
>
> we started sucessfully half a year ago and will continue to offer the MSc 
> Atmospheric Science next autumn. A full description of the international 
> program is offered at the program's website 
> (www.mi.uni-hamburg.de/atmo-science)and a quick overview is summarized in a 
> leaflet 
> (https://www.mi.uni-hamburg.de/en/studium/files/atmoscienceannouncement.pdf).
>
> Please feel free to distribute this information widely in your networks! We 
> are looking forward to applications until *31 March 2024*.
>
> Cheers,
>
> Felix Ament
>
> -- 
>
> Prof. Dr. Felix Amenthttp://www.mi.uni-hamburg.de
> Meteorologisches Institut, Univ. Hamburg,  phone: +49-40-42838 3597
> Bundesstr. 55, 20146 Hamburg, Germany  fax:   +49-40-42838 5452
> (also at Max-Planck-Institut für Meteorologie, phone: +49-40-41173 277)
> ___
> Members.cen mailing list
> members@lists.uni-hamburg.de
> https://lists.uni-hamburg.de/mailman/listinfo/members.cen

smime.p7s
Description: S/MIME digital signature

Re: Kristineberg ARTS workshop 2024, register now

[Stefan Buehler]

Dear all,

the registration form is working again.

Stefan

On 30 Jan 2024, at 16:31, Lemke, Oliver wrote:

> Hi all,
>
> Unfortunately, due to technical issues with our university's web service, the 
> registration form is currently unavailable. We are working with our IT 
> department to resolve this issue and get the registration form back online as 
> quickly as possible.
>
> Sorry for the inconvenience.
>
> Cheers,
> Oliver
>
>> On 30. Jan 2024, at 10:11, Stefan Buehler  
>> wrote:
>>
>> Dear all,
>>
>> summer 2024 is drawing closer, and so is the highlight of this summer, the 
>> ARTS radiative transfer workshop at Kristineberg research station, on the 
>> Swedish west coast.
>>
>> The workshop will be on June 4-7, 2024 (from noon to noon). The target 
>> audience are users and developers of the atmospheric radiative transfer 
>> simulator ARTS, and also anyone interested in spectroscopy or radiation that 
>> can give us new impulses.
>>
>> Anticipated topics are:
>> Gas absorption
>> Scattering
>> Surface interaction
>> The shortwave side of things (since this is new in ARTS)
>> ARTS applications
>> New sensors
>>
>> We anticipate that there will be dedicated talks sessions on these topics, 
>> plus posters, and also space for informal discussion and practical help with 
>> ARTS. Please indicate your contribution(s) with the registration, we will 
>> then compile an explicit agenda.
>>
>> Some practicalities:
>>
>> There will be a free bus transfer from Göteborg on June 4 at 10:00, and back 
>> to Göteborg on June 7, arriving approximately at 15:00. The workshop fee is 
>> around 460€ all inclusive if you stay at the research station, and 
>> approximately 280€ (including lunch and dinner) if you stay at one of the 
>> nearby hotels (plus the cost of the hotel). You pay the fee directly to the 
>> research station's staff (only card payment). The number of participants is 
>> limited to 50, due to the size of the bus, and the number of beds at the 
>> research station itself is limited to 45, so register soon if you want to 
>> take part!
>>
>> Note also that there are only a few single rooms at the research station, so 
>> most people staying on-site will have to share a double room. The 
>> registration form allows you to indicate if room sharing is ok for you or 
>> not.
>>
>> Registration: https://www.mi.uni-hamburg.de/arts2024
>>
>> Registration deadline: February 29
>>
>> Some useful links:
>>
>> Kristineberg marine research station:
>> https://www.gu.se/en/kristineberg
>>
>> Hotels within walking distance (Gullmarsstrand, Slipens):
>> https://gullmarsstrand.se/en/hotel/
>> https://www.slipenshotell.se/ (link seems not to work for some people, 
>> alternative: https://www.booking.com/Share-8DAo0f )
>>
>> Hoping to meet you in June!
>>
>> Patrick and Stefan

smime.p7s
Description: S/MIME digital signature

Kristineberg ARTS workshop 2024, register now

[Stefan Buehler]

Dear all,

summer 2024 is drawing closer, and so is the highlight of this summer, the ARTS 
radiative transfer workshop at Kristineberg research station, on the Swedish 
west coast.

The workshop will be on June 4-7, 2024 (from noon to noon). The target audience 
are users and developers of the atmospheric radiative transfer simulator ARTS, 
and also anyone interested in spectroscopy or radiation that can give us new 
impulses.

Anticipated topics are:
Gas absorption
Scattering
Surface interaction
The shortwave side of things (since this is new in ARTS)
ARTS applications
New sensors

We anticipate that there will be dedicated talks sessions on these topics, plus 
posters, and also space for informal discussion and practical help with ARTS. 
Please indicate your contribution(s) with the registration, we will then 
compile an explicit agenda.

Some practicalities:

There will be a free bus transfer from Göteborg on June 4 at 10:00, and back to 
Göteborg on June 7, arriving approximately at 15:00. The workshop fee is around 
460€ all inclusive if you stay at the research station, and approximately 280€ 
(including lunch and dinner) if you stay at one of the nearby hotels (plus the 
cost of the hotel). You pay the fee directly to the research station's staff 
(only card payment). The number of participants is limited to 50, due to the 
size of the bus, and the number of beds at the research station itself is 
limited to 45, so register soon if you want to take part!

Note also that there are only a few single rooms at the research station, so 
most people staying on-site will have to share a double room. The registration 
form allows you to indicate if room sharing is ok for you or not.

Registration: https://www.mi.uni-hamburg.de/arts2024

Registration deadline: February 29

Some useful links:

Kristineberg marine research station:
https://www.gu.se/en/kristineberg

Hotels within walking distance (Gullmarsstrand, Slipens):
https://gullmarsstrand.se/en/hotel/
https://www.slipenshotell.se/ (link seems not to work for some people, 
alternative: https://www.booking.com/Share-8DAo0f )

Hoping to meet you in June!

Patrick and Stefan


smime.p7s
Description: S/MIME digital signature

Re: [EXTERNAL] [BULK] 3D MC

[Stefan Buehler]

Dear Ian,

I also agree. In fact, I hope that we could use MC much more widely in some 
future version of ARTS, perhaps all the way down to MC sampling individual 
spectral lines.

/Stefan

On 7 Dec 2023, at 8:27, Patrick Eriksson wrote:

> Ian,
>
> Thanks for the input. Great that you have stress-tested MC. Too bad that it 
> revealed a limitation.
>
> Good suggestion about iyMC. Today it would not be possible to do the random 
> sampling from yCalc, it would require information on the sensor not at hand 
> inside yCalc today. But we are planning to redesign the way the sensor is 
> described, and this should be considered.
>
> Not totally sure exactly what you mean with using MC sampled antenna pattern 
> more broadly, but I tend to agree. It would be good if there would be 
> mechanisms to give monochromatic pencil beam calculations some width in 
> frequency and space. It would speed up simulations of observations. As 
> example, I have been playing around with a scheme to locally average the 
> surface emissivity around the point you hit the surface, to make simulations 
> in coastal areas faster.
>
> And yes, the most tricky part is finding the time for the work.
>
> Bye,
>
> Patrick
>
>
> On 2023-12-06 16:09, Adams, Ian S {he, him, his} (GSFC-6120) wrote:
>> Hi Stefan,
>>
>> I have been contemplating changes to the MC codes. One thing we have found 
>> is that MCGeneral breaks down when Q starts to get large. We see unrealistic 
>> results at 684 GHz when using horizontally aligned particles with high 
>> aspect ratio. Yuli Liu, who is working with us now, did comprehensive 
>> analysis, and we believe that the issue is the way the backwards algorithm 
>> is using importance sampling to avoid the issue of inverting the extinction 
>> matrix; however, this approach neglects the mixing of I and Q. I believe 
>> this is a simple fix.
>>
>> The other issue is that MCGeneral is not very ARTS-like. Looking at the way 
>> it is structured, I think a better approach would be to have an iyMC that 
>> traces a single "photon," and yMC would integrate these individual results. 
>> Random sampling of both the antenna pattern and the bandwidth could be 
>> performed at this level. I also think that the MC sampled antenna pattern 
>> could be more widely useful across ARTS.
>>
>> These papers provide an interesting curveball. The ARTS MC codes are 
>> particularly slow, and they are not optimized for optically thin or 
>> extremely optically thick atmospheres. We could look at using these 
>> libraries, or at least techniques, but I'm not sure how intensive such a 
>> restructuring of the code would be.
>>
>> Of course, the tricky piece here is finding someone with the time to do this 
>> work. But, I think these changes would make the codes significantly more 
>> usable, and hopefully therefore used.
>>
>> Cheers,
>> Ian
>>
>> On 11/29/23, 11:22 AM, "arts_dev.mi on behalf of Stefan Buehler" 
>> > <mailto:arts_dev.mi-boun...@lists.uni-hamburg.de> on behalf of 
>> stefan.bueh...@uni-hamburg.de <mailto:stefan.bueh...@uni-hamburg.de>> wrote:
>>
>>
>> Dear all,
>>
>>
>> I stumbled accross this interesting paper on an open C library for 
>> particularly efficient MC calculations. Could this be the basis of ARTS 3D 
>> MC flux and heating rate calculations? Using MC sampling also for the 
>> spectral dimension, to be efficient, as in the second paper, which is also 
>> impressive, I think. They use MC sampling even for the spectral lines, if I 
>> got it right! (Basically treating each transition as if it were its own 
>> absorption species.)
>>
>>
>> /Stefan
>>
>>
>> https://www.dropbox.com/scl/fi/smsisfgc2it3sx4gov970/J-Adv-Model-Earth-Syst-2019-Villefranque-A-Path-E2-80-90Tracing-Monte-Carlo-Library-for-3-E2-80-90D-Radiative-Transfer-in-Highly.pdf?rlkey=v5yvrm64fnljaf739j4ssllux=0
>>  
>> <https://www.dropbox.com/scl/fi/smsisfgc2it3sx4gov970/J-Adv-Model-Earth-Syst-2019-Villefranque-A-Path-E2-80-90Tracing-Monte-Carlo-Library-for-3-E2-80-90D-Radiative-Transfer-in-Highly.pdf?rlkey=v5yvrm64fnljaf739j4sslluxdl=0>
>>
>>
>> https://www.dropbox.com/scl/fi/r1tm3jdzx57kb85nowmt0/Yaniss_ea_PNAS_2023_smi.pdf?rlkey=8d4a7rb4u8pehckawbfk08c9f=0
>>  
>> <https://www.dropbox.com/scl/fi/r1tm3jdzx57kb85nowmt0/Yaniss_ea_PNAS_2023_smi.pdf?rlkey=8d4a7rb4u8pehckawbfk08c9fdl=0>
>>

smime.p7s
Description: S/MIME digital signature

3D MC

[Stefan Buehler]

Dear all,

I stumbled accross this interesting paper on an open C library for particularly 
efficient MC calculations. Could this be the basis of ARTS 3D MC flux and 
heating rate calculations? Using MC sampling also for the spectral dimension, 
to be efficient, as in the second paper, which is also impressive, I think. 
They use MC sampling even for the spectral lines, if I got it right! (Basically 
treating each transition as if it were its own absorption species.)

/Stefan

https://www.dropbox.com/scl/fi/smsisfgc2it3sx4gov970/J-Adv-Model-Earth-Syst-2019-Villefranque-A-Path-E2-80-90Tracing-Monte-Carlo-Library-for-3-E2-80-90D-Radiative-Transfer-in-Highly.pdf?rlkey=v5yvrm64fnljaf739j4ssllux=0

https://www.dropbox.com/scl/fi/r1tm3jdzx57kb85nowmt0/Yaniss_ea_PNAS_2023_smi.pdf?rlkey=8d4a7rb4u8pehckawbfk08c9f=0

smime.p7s
Description: S/MIME digital signature

Kristineberg 2024

[Stefan Buehler]

Dear all,

just a heads-up: we are planning a radiative transfer workshop next summer 
(June 4-7, 2024, from noon to noon) in Kristineberg, at the Swedish west coast. 
The target audience are users and developers of the atmospheric radiative 
transfer simulator ARTS, and also anyone interested in spectroscopy or 
radiation that can give us new impulses.

If you are interested, mark these days in your calendar. We will push out more 
information as the date draws nearer. Drop us an email if you want to be sure 
not to miss it.

Cheers,

Patrick and Stefan


smime.p7s
Description: S/MIME digital signature

Re: [arts-users] ARTS ICI Cloud Simulations

[Stefan Buehler]

No problem, just great, that you answered him already! Stefan

> Am 21.03.2022 um 16:24 schrieb Patrick Eriksson 
> :
> 
> Hi,
> 
> Sorry, I should have informed you. Kyle wrote to me on the side as well, and 
> I there asked for more details and then answered separately.
> 
> Not perfect. Next time I will force him to take all on arts-users.
> 
> Bye,
> 
> Patrick
> 
> 
> 
>> On 2022-03-21 11:46, stefan.bueh...@uni-hamburg.de wrote:
>> Hi all, is there anyone that can take this? Stefan
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> *Von: *Kyle Johnson >> >
>>> *Betreff: **[arts-users] ARTS ICI Cloud Simulations*
>>> *Datum: *13. März 2022 um 18:06:03 MEZ
>>> *An: *arts_users...@lists.uni-hamburg.de 
>>> 
>>> *Antwort an: *kyle.johnso...@colorado.edu 
>>> 
>>> 
>>> Hello,
>>> I was wondering if you all had a version of the controlfile ICI simulation 
>>> in ARTS that included clouds. My name is Kyle Johnson and I am a graduate 
>>> student at CU Boulder. I have been using the ICI simulation in ARTS as the 
>>> basis for an independent study project and need to add clouds in. I have 
>>> tried adding clouds in on my end and have been unsuccessful.
>>> Thank you for your time,
>>> Kyle Johnson (he/him/his)
>>> Graduate Student /University of Colorado Boulder/
>>> ___
>>> arts_users.mi mailing list
>>> arts_users...@lists.uni-hamburg.de 
>>> 
>>> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

Fwd: [arts-users] sensitivity of SAPHIR frequencies (183.31GHZ)

[stefan . buehler]

And this one? - Stefan

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Sisma Samuel 
> Betreff: [arts-users] sensitivity of SAPHIR frequencies (183.31GHZ)
> Datum: 15. März 2022 um 10:12:27 MEZ
> An: ARTS Users List 
> 
> Hi, 
> I was trying to simulate the sensitivity of  SAPHIR frequencies (183.31GHZ). 
> I tried to run 
> /home/nizy/arts-2.4.0/controlfiles/artscomponents/doit/TestDOIT.arts
> 
> To simulate for SAPHR frequencies by modifying doit_setup.arts
>  Frequency grid 
> # --
> # Note: The frequencies must be contained in the gas absorption lookup table.
> VectorSet( f_grid,183.31e9,1836.32e9] )
> 
> 
> but my output was
> This run took 0.06s (1.32s CPU time)
> Run-time error in controlfile: doit_setup_saphir.arts
> Run-time error in method: abs_lookupAdapt
> Cannot find new frequency 0 (1.8331e+11Hz) in the lookup table frequency grid.
> Stopping ARTS execution.
> 
> 
> Regards 
> Sisma
> ___
> arts_users.mi mailing list
> arts_users...@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

Fwd: [arts-users] ARTS ICI Cloud Simulations

[stefan . buehler]

Hi all, is there anyone that can take this? Stefan

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Kyle Johnson 
> Betreff: [arts-users] ARTS ICI Cloud Simulations
> Datum: 13. März 2022 um 18:06:03 MEZ
> An: arts_users...@lists.uni-hamburg.de
> Antwort an: kyle.johnso...@colorado.edu
> 
> Hello,
> I was wondering if you all had a version of the controlfile ICI simulation in 
> ARTS that included clouds. My name is Kyle Johnson and I am a graduate 
> student at CU Boulder. I have been using the ICI simulation in ARTS as the 
> basis for an independent study project and need to add clouds in. I have 
> tried adding clouds in on my end and have been unsuccessful.
> Thank you for your time,
> Kyle Johnson (he/him/his) 
> Graduate Student University of Colorado Boulder
> ___
> arts_users.mi mailing list
> arts_users...@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

Re: Eradiate Workshop 2022

[Stefan Buehler]

Hi Patrick,

I was thinking virtual participation, not someone actually traveling there.

Yves has this company rayference. They seem to manage to survive on Eu, Esa, 
and Eumetsat contracts. Perhaps being a company also helps, at least with the 
EU money, since it is often mandatory to have small enterprises involved.

Also, I believe that optical remote sensing of the surface is much more 
commercial than what we do. Perhaps they have also money from this area.

Stefan 

> Am 01.03.2022 um 09:55 schrieb Patrick Eriksson 
> :
> 
> Stefan and all,
> 
> I can  not go, busy with teaching and to high overall load. From the Chalmers 
> side, the best candidate is Vasilis. He has developed MC code for the optical 
> region. He is now in Greece and has a relatively short travel. But he is 
> employment at Chalmers ends June 30. So would be better if someone else could 
> go.
> 
> Stefan: Do you know more about how they got funding for this? Sounds as we 
> could promote ARTS as something similar for microwaves to IR. This looks at 
> the type of funding we have been lacking.
> 
> Bye,
> 
> Patrick
> 
> 
> 
> 
> 
>> On 2022-03-01 09:43, stefan.bueh...@uni-hamburg.de wrote:
>> Dear all,
>> I know Yves, so this is ligit. Perhaps someone from us should participate in 
>> the release workshop? This is perhaps similar to the 3-D Monte Carlo they do 
>> in Munich. But open. Focused on the solar spectral range, of course.
>> Stefan
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> *Von: *mailto:n...@eradiate.eu>>
>>> *Betreff: **Eradiate Workshop 2022*
>>> *Datum: *28. Februar 2022 um 16:58:41 MEZ
>>> *An: *mailto:stefan.bueh...@uni-hamburg.de>>
>>> 
>>> Dear Stefan Buehler,
>>> 
>>> You are receiving this email because you were identified as a radiative 
>>> transfer model user or developer.
>>> 
>>> The development ofEradiate <https://www.eradiate.eu/>, a new 3D radiative 
>>> transfer model, started in 2019 with the goal to create a novel simulation 
>>> platform for radiative transfer applied to Earth observation. Eradiate 
>>> intends to be highly accurate and uses advanced computer graphics software 
>>> as its Monte Carlo ray tracing kernel. It provides a modern Python 
>>> interface specifically designed for the integration in interactive 
>>> computing environments. It is also free software licensed under the GNU 
>>> Public License v3.
>>> 
>>> At the end of March 2022, Eradiate will be released to the public and open 
>>> to contribution from users. On this occasion, the Eradiate team will 
>>> organise a workshop, kindly hosted by ESA/ESRIN in Frascati on Tuesday 
>>> March 29^th and Wednesday March 30^th , 2022. This workshop will be 
>>> organised with a hybrid setup allowing for remote participants to attend. 
>>> Participation to the workshop is open and you can register by replying to 
>>> this email, providing the following information:
>>> 
>>> ·First name
>>> ·Last name
>>> ·Contact email address
>>> ·Affiliation
>>> 
>>> ·Whether you wish to join us in Frascati or prefer to attend remotely
>>> 
>>> Please be aware that the number of on-premises seats is limited, assigned 
>>> on a first come, first served basis. Registration for on-premises 
>>> participation will be closed on March 21^st , 2022.
>>> 
>>> The workshop announcement letter, with further information of the 
>>> programme, is availablehere 
>>> <http://eradiate.eu/resources/workshop/2022/documents/eradiate-ws-2022-announcement.pdf>.
>>>  You can alsoregister to our mailing list <http://eepurl.com/dwpaOz>if you 
>>> want to be updated about Eradiate in the future.
>>> 
>>> Kind regards,
>>> 
>>> Yves Govaerts, for the Eradiate Team
>>> 

Fwd: Eradiate Workshop 2022

[stefan . buehler]

Dear all,

I know Yves, so this is ligit. Perhaps someone from us should participate in 
the release workshop? This is perhaps similar to the 3-D Monte Carlo they do in 
Munich. But open. Focused on the solar spectral range, of course.

Stefan

> Anfang der weitergeleiteten Nachricht:
> 
> Von: 
> Betreff: Eradiate Workshop 2022
> Datum: 28. Februar 2022 um 16:58:41 MEZ
> An: 
> 
> Dear Stefan Buehler,
> 
> You are receiving this email because you were identified as a radiative 
> transfer model user or developer. <>
> The development of Eradiate <https://www.eradiate.eu/>, a new 3D radiative 
> transfer model, started in 2019 with the goal to create a novel simulation 
> platform for radiative transfer applied to Earth observation. Eradiate 
> intends to be highly accurate and uses advanced computer graphics software as 
> its Monte Carlo ray tracing kernel. It provides a modern Python interface 
> specifically designed for the integration in interactive computing 
> environments. It is also free software licensed under the GNU Public License 
> v3.
> 
> At the end of March 2022, Eradiate will be released to the public and open to 
> contribution from users. On this occasion, the Eradiate team will organise a 
> workshop, kindly hosted by ESA/ESRIN in Frascati on Tuesday March 29th and 
> Wednesday March 30th, 2022. This workshop will be organised with a hybrid 
> setup allowing for remote participants to attend. Participation to the 
> workshop is open and you can register by replying to this email, providing 
> the following information:
> 
> · First name
> · Last name
> · Contact email address
> · Affiliation
> · Whether you wish to join us in Frascati or prefer to attend remotely
> 
> Please be aware that the number of on-premises seats is limited, assigned on 
> a first come, first served basis. Registration for on-premises participation 
> will be closed on March 21st, 2022.
> 
> The workshop announcement letter, with further information of the programme, 
> is available here 
> <http://eradiate.eu/resources/workshop/2022/documents/eradiate-ws-2022-announcement.pdf>.
>  You can also register to our mailing list <http://eepurl.com/dwpaOz> if you 
> want to be updated about Eradiate in the future.
> 
> Kind regards,
> 
> Yves Govaerts, for the Eradiate Team
> 

Re: ReadHITRAN

[Stefan Buehler]

Dear Patrick,

I think we should put ARTS’ own line catalog in the center wherever possible 
(which is based on converted current HITRAN). Use it, if you are happy with the 
parameters there. If you want other parameters, and there is a good reason for 
that, consider updating it. We have a mechanism to replace individual 
parameters there (and document those substitutions).

Stefan

On 20 Sep 2021, at 10:46, Patrick Eriksson wrote:

> Richard,
>
> Thanks for additional information. Seems that the take home message is that I 
> should look at other ways to set up the calculations. I just picked up an old 
> cfile, used that as a starting point and did not even consider alternatives 
> to use ReadHITRAN.
>
> Bye,
>
> Patrick
>
> On 2021-09-20 09:05, Richard Larsson wrote:
>> 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 line always.  This is because 
>> we keep line data local, and the model for the line shape and the local 
>> quantum numbers don't have to be known at compile-time.
>>
>> Additionally, the line data is pushed into arrays, so they will double in 
>> size every time you reach the current size.
>>
>> If we knew the number of lines and broadening species and local quantum 
>> numbers, then these allocations happen once for the entire band, but we 
>> don't in ReadHITRAN or any of the external reading routines.  So you will 
>> have many-many system calls asking for more memory.  This of course also 
>> means that you are over-allocating memory since that's how Arrays work in 
>> ARTS (because that's standard C++).  Again, this is also fine since the 
>> external catalog when read again will allocate only exactly what is required.
>>
>> With hope,
>> --Richard
>>
>> Den mån 20 sep. 2021 kl 08:09 skrev Patrick Eriksson 
>> mailto:patrick.eriks...@chalmers.se>> :
>>
>> Richard,
>>
>> Thanks for the clarification.
>>
>> Is the allocation of more memory done in fixed chunks? Or something
>> "smart" in the process? If the former and the chunks are too small,
>> then
>> maybe I am doing a lot of reallocations. My impression was that memory
>> usage increased quite monotonically, not in noticeable steps.
>>
>> If the lines have to be sorted into bands, then the complexity of the
>> reading will increase in line with what I have noticed. And likely not
>> much to do about it.
>>
>> Bye,
>>
>> Patrick
>>
>>
>>
>>  > 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 there are more bands to
>> look through.
>>  >
>>  > The former would be just pure bad luck, so there's nothing to do
>> about it.
>>  >
>>  > I would suspect the latter is your problem.  You need to search
>> through
>>  > the existing bands for every new line to find where it belongs. 
>> Since
>>  > bands are often clustered closely together in frequency, this
>> could slow
>>  > down the reading as you get more and more bands. A smaller frequency
>>  > range means fewer bands to look through.
>>  >
>>  > //Richard
>>  >
>>  > On Sun, Sep 19, 2021, 22:39 Patrick Eriksson
>>  > > 
>> > >> wrote:
>>  >
>>  >     Richard,
>>  >
>>  >      > It's expected to take a somewhat arbitrary time.  It reads
>> ASCII.
>>  >
>>  >     I have tried multiple times and the pattern is not changing.
>>  >
>>  >
>>  >      > 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.
>>  >
>>  >     Understood. But that overhead seems to be relatively small.
>> In my test,
>>  >     it seemed to take 4-7 s to reach the first frequency. Anyhow,
>> this goes
>>  >     in the other direction. To minimise the parsing to reach the
>> first
>>  >     frequency, it should be better to read all in one go, and not
>> in parts
>>  >     (which is the case for me).
>>  >
>>  >     Bye,
>>  >
>>  >     Patrick
>>  >
>>

Re: VMRs

[Stefan Buehler]

You are right, the cross dependence would still be there, and come through the 
dry pressure, which gets smaller when there is more water vapor.

Overall, I also still like the option to rescale the VMRs better.

/Stefan

On 16 Sep 2021, at 21:34, Patrick Eriksson wrote:

> Stefan,
>
>>> For HSE it is up to the user to apply this "fine tuning" or not. This 
>>> including to include adding call of the HSE method in OEM iterations, to 
>>> make sure that HSE is maintained after an iteration. The VMR rescaling 
>>> should also be included in the iteration agenda, if the retrieval can 
>>> change H2O close to the ground. That is, a VMR rescaling would not be 
>>> something completely new, as I see it.
>>
>> It seems to me that this leads into a logical loop: If you retrieve H2O and 
>> O3, and the retrieved H2O value directly affects the O3 value due to the 
>> rescaling. As you write, in principle, this should even be in the Jacobian, 
>> as a cross-term. With more water, the lines of all other gases get weaker.
>>
>> It is true that if there is more of the one there has to be less of the 
>> other, but argh, this is so ugly.
>>
>> Perhaps the deeper reason why AER went for the other definition? If VMRs 
>> refer to the dry pressure, and the dry gases are all either quite constant 
>> or very rare, then retrievals are more independent.
>
> To switch to the other definition, than the VMR of e.g. N2 would stay the 
> same in a retrieval of H2O. This is why I initially found this option nice. 
> But it would not change the physics and the cross-dependences between species 
> would not disappear. You have to remember that VMR is a relative measure. To 
> get the absolute amount of the species, you still need to calculate the 
> partial pressures. That is you need to "distribute" the total pressure among 
> the gases, and as I understand it a general expression for this would be:
>
> p_i = VMR_i * p / VMR_sum
>
> where p_i is partial pressure of species i, VMR_i its VMR, p pressure and 
> VMR_sum the sum of all VMRs.
>
> Our present definition is based on that VMR_sum=1, while in the alternative 
> version it will deviate, and with more H2O VMR_sum will increase which will 
> affect p_i even if VMR_i is unchanged.
>
> Or do I miss something?
>
> Bye,
>
> Patrick

Re: VMRs

[Stefan Buehler]

Hej igen,

> Yes, this puts some weight on the user. Hydrostatic equilibrium (HSE) is a 
> similar case. Input profiles do not always fulfil HSE (this is the case for 
> Fascod, if not a mater of geopotential vs geometric altitudes?).

Could this for Fascod also be due to the VMR definition, perhaps?

> For HSE it is up to the user to apply this "fine tuning" or not. This 
> including to include adding call of the HSE method in OEM iterations, to make 
> sure that HSE is maintained after an iteration. The VMR rescaling should also 
> be included in the iteration agenda, if the retrieval can change H2O close to 
> the ground. That is, a VMR rescaling would not be something completely new, 
> as I see it.

It seems to me that this leads into a logical loop: If you retrieve H2O and O3, 
and the retrieved H2O value directly affects the O3 value due to the rescaling. 
As you write, in principle, this should even be in the Jacobian, as a 
cross-term. With more water, the lines of all other gases get weaker.

It is true that if there is more of the one there has to be less of the other, 
but argh, this is so ugly.

Perhaps the deeper reason why AER went for the other definition? If VMRs refer 
to the dry pressure, and the dry gases are all either quite constant or very 
rare, then retrievals are more independent.

/Stefan

Re: arts_dev.mi Digest, Vol 52, Issue 1

[Stefan Buehler]

Dear Stuart,

yes, exactly, thanks for pointing this out. :-) I had completely forgotten 
about this.

This problem is related but slightly different: The VMR profile that we get as 
input may be based on the convention that x = p_species/p_dry, rather than 
p_species/p_total.

I just quickly checked the FASCOD profiles that we distribute with 
arts-xml-data. Looking at O2 and N2, it seems to me that they clearly follow 
this convention (the numbers for O2 are constant almost to the top).

That means, we have been interpreting them slightly wrong all these years, I’m 
afraid.

To fix the particular issue with the FASCOD data, I guess a condensibles 
argument, similar to the one for atm_fields_compactAddConstant for AtmRawRead 
could be a solution.

What makes this a bit messy is that there are quite a few ways in which we can 
ingest data. We would have to figure out where else to add this extra argument. 
But one other main way, reading in atm_fields_compact, uses a generic method, 
so that approach doesn’t even work.

Another solution could be to make a method that does the rescaling on the 
fields after they are read (but before the calculation). Something like

vmr_fieldRescaleForDryPressureVMRInputData(vmr_field, abs_species, condensibles)

Right now I would say that is the best solution, since it is easy and fixes the 
problem in one place. The only (quite significant) downside I see is that it is 
not at all foolproof, since it can easily be omitted.

/Stefan

On 16 Sep 2021, at 12:40, Fox, Stuart wrote:

>> It seems a bit weird to me to use this definition at the (low) level of the 
>> absorption routines. Perhaps one solutions would be to have an option for 
>> this behaviour when ingesting concentration profile data? Perhaps by > 
>> passing in a list of species that should be considered as not adding to the 
>> denominator for the VMR definition.
>
> Is this behaviour not what the "condensibles" argument to 
> atm_fields_compactAddConstant already does? That was my understanding from 
> reading the documentation!
>
> I'm quite happy with the definition of VMR as it is, having just spent ages 
> trying to get my head around what the "correct" VMRs for O2 and N2 are to 
> pass to the legacy complete absorption models in order to reproduce the 
> expected absorption, since lots of these models seem to have a default 
> assumption about what the VMR is built in to the line-strength constants.
>
> Stuart

Re: VMRs

[Stefan Buehler]

Hej,

> With our present definition of VMRs, we agree on that having 78% N2, 21% O2 
> and e.g. 3% H2O is unphysical? That with a lot of H2O (or any other non-fixed 
> gas) the standard values of the fixed gases should be scaled downwards. In 
> the example above, with 0.97. Do you agree?

Yes, I agree.

>> It seems a bit weird to me to use this definition at the (low) level of the 
>> absorption routines. Perhaps one solutions would be to have an option for 
>> this behaviour when ingesting concentration profile data? Perhaps by passing 
>> in a list of species that should be considered as not adding to the 
>> denominator for the VMR definition.
>
> If we agree on the above, then this is the simplest (but not most 
> theoretically correct) solution.

Why not correct?

/Stefan

Re: VMRs

[Stefan Buehler]

Hej Patrick!

It seems a bit weird to me to use this definition at the (low) level of the 
absorption routines. Perhaps one solutions would be to have an option for this 
behaviour when ingesting concentration profile data? Perhaps by passing in a 
list of species that should be considered as not adding to the denominator for 
the VMR definition.

Note that for once the special thing about water is here not the fact that it’s 
condensible, I think, but just that there is so much of it, and at the same 
time very variable. Other gas species have also very variable concentrations, 
but it doesn’t matter for the total pressure.

All the best,

Stefan

On 15 Sep 2021, at 20:19, Patrick Eriksson wrote:

> Stefan,
>
> Neither I had considered this definition of VMR. But would it not make sense 
> to follow it? Then a statement that the atmosphere contains 20.95% oxygen 
> makes more sense. You yourself pointed at that it would make sense to scale 
> N2 and O2 for low humid altitudes, where the amount of water can be several 
> %. In code preparing data for ARTS I normally do this adjustment. Should be 
> more correct!?
>
> A problem is to define what is the wet species when we go to other planets. 
> Or maybe there are even planets with several wet species?
>
> That is, I would be in favour to define VMR with respect to dry air, if we 
> can find a manner to handle other planets.
>
> Bye,
>
> Patrick
>
>
>
> On 2021-09-15 18:27, Stefan Buehler wrote:
>> Dear all,
>>
>> Eli Mlawer brought up an interesting point in some other context:
>>
>>> we recently had a LBLRTM user get confused on our vmr, which is 
>>> amount_of_gas / amount_of_dry_air. They weren’t sure that dry air was the 
>>> denominator instead of total air.  I’m too lazy to look at the link above 
>>> that @Robert Pincus provided, but I hope it is has dry air in the 
>>> denominator.  So much easier to simply specify evenly mixed gases, such as 
>>> 400 ppm CO2 (and, 20 years from now, 500 ppm CO2).
>>
>> I’ve never considered that one could define it this way. Perhaps this 
>> convention explains, why VMRs in climatologies like FASCOD add up so poorly 
>> to 1.
>>
>> I’m not suggesting that we change our behaviour, but want to make you aware 
>> that this convention is in use. (Or perhaps you already were, and just I 
>> missed it.)
>>
>> All the best,
>>
>> Stefan
>>

VMRs

[Stefan Buehler]

Dear all,

Eli Mlawer brought up an interesting point in some other context:

> we recently had a LBLRTM user get confused on our vmr, which is amount_of_gas 
> / amount_of_dry_air. They weren’t sure that dry air was the denominator 
> instead of total air.  I’m too lazy to look at the link above that @Robert 
> Pincus provided, but I hope it is has dry air in the denominator.  So much 
> easier to simply specify evenly mixed gases, such as 400 ppm CO2 (and, 20 
> years from now, 500 ppm CO2).

I’ve never considered that one could define it this way. Perhaps this 
convention explains, why VMRs in climatologies like FASCOD add up so poorly to 
1.

I’m not suggesting that we change our behaviour, but want to make you aware 
that this convention is in use. (Or perhaps you already were, and just I missed 
it.)

All the best,

Stefan

Fwd: [Members.cen] [mpicen] TODAY 13:30h Special Virtual Joint Seminar: Good Scientific Code - What, Why, How

[Stefan Buehler]

Dear all,

I want to advertise this seminar in particular. An important topic!

Cheers

Stefan

Forwarded message:


From: Jimenez, Diego 
To: mpi...@uni-hamburg.de
Subject: [Members.cen] [mpicen] TODAY 13:30h Special Virtual Joint 
Seminar: Good Scientific Code - What, Why, How

Date: Wed, 9 Jun 2021 06:37:05 +

Dear Colleagues,

Today Wednesday June 9 from 13:30 to 15:40, George Datseris will 
present his thoughts on how to better our scientific coding. The 
importance of (i) having streamlined scripts for processing the data 
that supports our articles, easing the reproducibility, and (ii) a 
reliable and tested code base are some of the topics that will be 
treated in this talk and that should be of interest for all of us. We 
provide the title of the talk and its abstract below, as well as the 
Zoom meeting link.


We hope to see many of you in the Zoom-webinar.

This will be a longer-than-usual seminar-workshop. There will be a 
10-minute break in the middle, for you to revitalise with a coffee.


Wednesday Special Joint Seminar - George Datseris
9 June 2021 13:30 - 15:40

Join zoom meeting
https://zoom.us/j/95776977544?pwd=aDE3WU02ejkrSDBaRzM3Yk12MzFtZz09

Meeting ID: 957 7697 7544
Passcode: 657522
One tap mobile
+496971049922,,95776977544# Germany
+493056795800,,95776977544# Germany

Dial by your location
+49 69 7104 9922 Germany
+49 30 5679 5800 Germany
+49 695 050 2596 Germany
Meeting ID: 957 7697 7544
Find your local number: https://zoom.us/u/aFxzbhSm4

Cheers,

Armin, Diego, and Shih-Wei


Good Scientific Code - What, Why, How


Scientific code is notorious for appearing sloppy, hard to read and 
navigate, full of duplication, and difficult to reproduce. The main 
reason this happens is because curricula that traditionally train 
scientists pay little attention to writing good code, and during the 
scientific life there is little time for the individual to practice 
this on their own. In this short workshop we will change that! The two 
main parts we will discuss are writing good code and incorporating 
software development paradigms into your workflow. If time permits, we 
will also have a look at version control, code collaboration and 
reproducible code publishing.


---
Dr Diego Jiménez-de-la-Cuesta Otero
Postdoc in the AES/GCC Group
Max-Planck-Institut für Meteorologie
Bundesstraße 53, Office B415
20146 Hamburg
Deutschland

Tel.: +49 (0) 40 41173 416

___
Members.cen mailing list
members@mailman.rrz.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/members.cen

Fwd: [arts-users] Calculated brightness temperature bias causes.

[Stefan Buehler]

Hi all,

could someone who knows answer him, please?

/Stefan

Forwarded message:


From: Thomas,Renish 
To: Richard Larsson 
Cc: Stefan Buehler , 
arts_users...@lists.uni-hamburg.de 

Subject: Re: [arts-users] Calculated brightness temperature bias 
causes.

Date: Wed, 21 Apr 2021 21:16:37 +

Thank you, Richard and Stefan,

Yes, that is the difference that I am getting at 183 GHz.

Does the scattering calculation methods in ARTS even now accept only 
RJBT units ? Are Planck units going to be enabled for scattering 
solvers anytime soon?


Thanks,
Renish

From: Richard Larsson 
Sent: Tuesday, April 20, 2021 5:42 AM
To: Thomas,Renish 
Cc: Stefan Buehler ; 
arts_users...@lists.uni-hamburg.de 

Subject: Re: [arts-users] Calculated brightness temperature bias 
causes.


Hi,

Just by numbers:

RJBT at 300 K 183 GHz is 3.086705214957283e-15

Planck at 300 K 183 GHz is 3.0417434132511342e-15

This means you expect a 1.5 % difference, or about 4.5 K between them.

With hope,
//Richard

Den tis 20 apr. 2021 kl 13:22 skrev Thomas,Renish 
mailto:renish.tho...@colostate.edu>>:

Hi Stephan,

I am using Rayleigh jeans. As I need to activate cloud box in some 
instances.


I understand that RJBT instead of Planck can cause a dip in the 
brightness temperatures. Is this the only factor that can cause a 
bias, or does pressure levels, lat/lon grid resolution also cause a 
bias?


Thanks,
Renish


 Original message 
From: Stefan Buehler 
mailto:stefan.bueh...@uni-hamburg.de>>

Date: 4/20/21 6:11 AM (GMT-06:00)
To: "Thomas,Renish" 
mailto:renish.tho...@colostate.edu>>
Cc: 
"arts_users...@lists.uni-hamburg.de<mailto:arts_users...@lists.uni-hamburg.de>" 
mailto:arts_users...@mailman.rrz.uni-hamburg.de>>
Subject: Re: [arts-users] Calculated brightness temperature bias 
causes.


Dear Renish,

do you use Planck or Rayleigh-Jeans brightness temperature? For 
Planck,
you should indeed approach the ambient temperature if you go low 
enough.


Cheers

Stefan

On 20 Apr 2021, at 12:46, Thomas,Renish wrote:


Hi Everyone,

I had some questions about the calculated brightness temperature in
ARTS.

When I calculate the brightness temperature for an atmospheric
scenario in "horizon looking mode" and in clearsky. I get a 
brightness

temperature at 183.31 GHz (Water vapor absorption line), which is
about 3 to 6 degrees lower than the ambient temperature.

I would assume that at the water vapor absorption line and at low
altitudes (~2 km above sea level), I should measure very close to the
ambient temperature (Due to high absorption).

So, my questions are:

1.)  Is this brightness temperature bias expected?, or can something
else cause this?

Thanks,
Renish
___
arts_users.mi mailing list
arts_users...@lists.uni-hamburg.de<mailto:arts_users...@lists.uni-hamburg.de>
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.midata=04%7C01%7CRenish.Thomas%40colostate.edu%7C8bb1cd94b52a4724954408d903ed19cb%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545139171957024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=7Qr43Du%2B54FAx%2FWFOIMnjdaHFegsWnBRslp2jGQYxb8%3Dreserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi=04%7C01%7CRenish.Thomas%40colostate.edu%7C3cb4ae984f594bc5fc1408d903f16e00%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545157742334188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=rAhkk83NkUW%2B6P7%2FQRS8%2FHW4h2Q12rLfUHYPz11kY0U%3D=0>

___
arts_users.mi mailing list
arts_users...@lists.uni-hamburg.de<mailto:arts_users...@lists.uni-hamburg.de>
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi=04%7C01%7CRenish.Thomas%40colostate.edu%7C3cb4ae984f594bc5fc1408d903f16e00%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545157742339161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=p80qF1gIuNiInE4syM5IUH%2B8JQSbdFojjKj3X1XE2b4%3D=0>

Re: New Koshelev Paper

[Stefan Buehler]

Hi again,

Viju pointed out that the pdf is difficult to get (damn Elsevier). Hier 
is a preprint version:

https://www.dropbox.com/s/w302zg9u2mqe5d3/koshelev2020.pdf?dl=0

/Stefan

On 26 Apr 2021, at 12:52, Stefan Buehler wrote:


Hi all,

perhaps of interest for some of you:

Water vapor line profile at 183-GHz: Temperature dependence of 
broadening, shifting, and speed-dependent shape parameters, Koshelev 
et al., DOI: 10.1016/j.jqsrt.2020.107472


/Stefan

New Koshelev Paper

[Stefan Buehler]

Hi all,

perhaps of interest for some of you:

Water vapor line profile at 183-GHz: Temperature dependence of 
broadening, shifting, and speed-dependent shape parameters, Koshelev et 
al., DOI: 10.1016/j.jqsrt.2020.107472


/Stefan

Fwd: Microwave retrieval paper

[Stefan Buehler]

Forwarded message:


From: Baran, Anthony 
To: Stefan Buehler 
Subject: RE: Microwave retrieval paper
Date: Thu, 18 Feb 2021 08:54:53 +

Actually Stefan, the special issue is now remaining open for 
submission of papers until 1st July - so your group could submit one. 
There are two published so far 
https://www.mdpi.com/journal/remotesensing/special_issues/Scatter_Ice_Crystals


Regards,

Anthony

-Original Message-
From: Stefan Buehler 
Sent: 18 February 2021 08:49
To: Baran, Anthony 
Subject: Re: Microwave retrieval paper

This email was received from an external source.   Always check sender 
details, links & attachments.


Dear Anthony,

thanks for the heads up!

Best wishes,

Stefan

On 18 Feb 2021, at 9:39, Baran, Anthony wrote:


Hi both,

The following paper on microwave retrieval of ice cloud properties
ought to be of interest to you and your colleagues. It was published
yesterday in the Remote Sensing special issue on ice crystal
scattering.

Remote Sensing | Free Full-Text | Passive Remote Sensing of Ice Cloud
Properties at Terahertz Wavelengths Based on Genetic Algorithm
(mdpi.com)<https://www.mdpi.com/2072-4292/13/4/735>

Regards, Anthony

Re: Simon plans for scattering properties

[Stefan Buehler]

Hej Richard,

to me the interesting point is that the specific inputs could be handled 
where the “Add..Habit” happens. In the case of absorption, a lot of 
difficulty comes from the dichotomy between the species tags and the 
methods that have to be added to the absorption agenda to actually do 
the calculations. Using Simons concept, one could potentially replace 
the tags by something like


AbsorberAppendLBL(“H2O”)
AbsorberAppendCIA(“N2-O2”)
AbsorberAppendLBL(“O3”)
AbsorberAppendXsec(“CFC-11”)

So, instead of indentifying the model to be used by the tag name, we 
could identify it by the Add method used. The different Add methods 
would depend on different input variables, such as line catalog, 
tabulated cross-sections, etc.. That solution seems quite elegant to me.


One problem is, though, that one absorption tag currently can be a 
combination of models for the same gas species. One way to solve this 
would be to have two types of methods, Add and Append, like this:


AbsorberAppendLBL(“H2O”)
AbsorberAddCont(“H2O”,”CKD-MT-3_7)
AbsorberAppendCIA(“N2-O2”)
AbsorberAppendLBL(“O2”)
AbsorberAddCont(“O2”,”PWR20”)
AbsorberAppendXsec(“CFC-11”)

A strict interface for the output is no problem, since all absorption 
functions produce exactly the same output.


For the (atmospheric) input it is potentially more problematic. For 
example, Zeeman absorption depends on the magnetic field, but none of 
the other absorption functions do.


I don’t think there is so much overhead that one really gains a lot by 
for example doing all the LBL species in one go. One could basically use 
the present lower level functions, and just call them repeatedly for 
each gas in turn. When the absorption lookup table is generated, I think 
it is already done this way.


AbsorberAppendLBL would depend on abs_lines_per_species, and just 
incorporate the lines for the species in questions to the local data of 
the AbsorberLBL class, inheriting the public interface from the general 
Absorber class.


So, I think in principle this structure could be built on top of the 
various absorption functions we have, replacing the current tag 
mechanism.


Ah, there probably are a lot of pitfalls.

One that I just noticed is that, if the species list is only established 
by these Append methods, then we have no good way to decide for which 
species we should read in the line catalogue data. (For that the list of 
species of interest would have to be defined before.) This could be 
solved by the Append method doing the catalog reading, but that would 
make the Append methods quite heavy. On the other hand it would make for 
very short and simple controlfiles, the call would be like:


AbsorberAppendLBL(,“H2O”)

I’m not sure whether I like that, though, it seems less flexible than 
what we have when it comes to dealing with the catalog.


All the best,

Stefan

On 1 Feb 2021, at 16:10, Richard Larsson wrote:


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 not going to argue for the scattering implementation here because 
I
assume you guys know the current interface well enough and have ideas 
of
how to easily extend it using the new and old methods.  Perhaps the 
strict

interface helps here.

I would not mind having a "void *" list/vector in the LBL code but I 
am
very wary about the strict interface requirements here.  I would be 
much
more accepting if we could just get some kind of "const ClassImpl&" 
back
from the "void *" list.  Then the different methods can much more 
easily
know if they need to write to src or not, to a PropagationMatrix 
interface

or to an ArrayOfMatrix interface.

I don't like the idea of separating this by species in the LBL though. 
 It
would be much better to separate it by the types of calculations 
necessary
(the SpeciesTag-enum + the Absorption::PopulationType enum for LBL).  
That
way you could probably allow pre-allocations of all allocated 
variables
used by the algorithms taking the class without having to worry too 
much
about the memory footprint and leaving deallocation or reuse up to the 
user

(a cleanup method or more in the Agenda).

That said, I think it is quite a daunting task to change things this 
way.

And I am not sure how easy it is to take Simon's idea and use it with
value-semantics.

With hope,
//Richard

Den mån 1 feb. 2021 kl 14:14 skrev Stefan Buehler <
stefan.bueh...@uni-hamburg.de>:


Dear Simon,


The handling of the constant data is completely up to the
implementation of the specific scatterers.
For the ScatteringParticle class, for example, this is provided when
the object is constructed.
So when the ARTS user calls:

scattering_speciesAddScatteringHabit(...)

an obj

Re: Simon plans for scattering properties

[Stefan Buehler]

Dear Simon,

The handling of the constant data is completely up to the 
implementation of the specific scatterers.
For the ScatteringParticle class, for example, this is provided when 
the object is constructed.

So when the ARTS user calls:

scattering_speciesAddScatteringHabit(...)

an object is created which will hold the scattering data. It will then 
use it when asked to
compute the bulk scattering properties. Since the 
calculate_bulk_properties(...) method
is called on this object, it automatically has access to the required 
data.


Ah, yes. That is a great solution. Perhaps I could do the same for the 
absorbers. But I would have to break up the methods so that they are 
standalone for each absorption tag. Right now, the method that does LBL, 
for example, will calculate for all the LBL absorption tags, using a 
common workspace variable for the line catalog (which is internally 
split by species). All the housekeeping around this is a lot of trouble. 
Perhaps it would be better to always run it just for a single absorber, 
and use a technique similar to yours to set up the list, so that each 
absorber gets the line list he needs. (And similarly for the other types 
of absorption.)


/Stefan

Re: Simon plans for scattering properties

[Stefan Buehler]

Dear Simon,

how will you manage communication? I’m asking because there is a 
related issue in computing absorption. It is easy to define a common 
interface with respect to what the functions have to provide. But in 
that case (and perhaps also in your case) a problem is that they require 
quite different input, in addition to the atmosphere. (In the case of 
absorption for example spectral line data for LBL functions, or a table 
with measured cross-section data for other functions.)


Best wishes,

Stefan

On 31 Jan 2021, at 10:53, Simon Pfreundschuh wrote:


Dear Stefan,


If there's no user-configurable parameters required for molecular 
scattering then


using it in a control file would be trivial:


scattering_species_AddMolecularScattering()


The iy method would then just need to check if the sun is on and 
calculate


the bulk scattering properties for the first order scattering. In this 
way particles


and molecules would be handle in a consistent way.


What is required for this to work is of course a class that implements 
the interface


defined by the ScatteringSpeciesImpl class (as indicated in the PDF).


I also would really like to highlight the following, which you seem to 
have

misunderstood:


The interface that I described makes no assumptions whatsoever on the 
scattering


species being either particles or a gas. It essentially already 
implements what


you described but is even less restrictive. It only requires that a 
scattering species


is able to provide bulk scattering data from an atmospheric state 
following the


protocol defined by the ScatteringSpeciesImpl class.

I am quite sure that with this system molecular and particle 
scattering can
be handled consistently and the need for a molecular_scattering flag. 
However,
I also agree that it would probably be inappropriate to  require Jon 
to use this
system considering that he's just a Master's student and that this is 
still under

development.

Kind regards,

Simon




From: arts_dev.mi-boun...@mailman.rrz.uni-hamburg.de 
 on behalf of Stefan 
Buehler 

Sent: Friday, January 29, 2021 8:42:21 AM
To: Simon Pfreundschuh
Cc: ARTS Developers List
Subject: Re: Simon plans for scattering properties

Hej Simon,

can you help me understand it then, please? I do want to find the best
solution, not necessarily the quickest. (But simplicity is part of the
criteria for “best”.)

/Stefan

On 29 Jan 2021, at 7:11, Simon Pfreundschuh wrote:


Dear Stefan,


I guess all I can say is that I am quite confident that you didn't
properly

understand my proposal, which could quite easily handle the pressure

dependency. Anyhow, it's quite clear that you are searching for a
quick

solution and I won't be able to provide that. So let's just cut this
short.


/s




From: Stefan Buehler 
Sent: Thursday, January 28, 2021 5:02:28 PM
To: Simon Pfreundschuh
Cc: ARTS Developers List
Subject: Re: Simon plans for scattering properties

Dear Simon,

thanks for the summary!

I think I understand more or less how this works now. A bit
unfortunate
that so much information has to be moved around at the controlfile
level. (The copying of grids from one variable to the other, the
copying
of the scattering data themselves.) Is the idea that you would then 
in

practise store and load directly the ScatteringHabits, in order to
make
this easier?

On where the Rayleigh scattering fits in: Patrick suggested when we
talked yesterday that perhaps a more logical way to think about this
is
to distinguish between *gases* and *particles*, rather than between
*absorption* and *scattering*. (Including Rayleigh scattering with 
the

PND system really does not work, as it turns out, as it depends on
pressure.)

Perhaps we should move towards a *gas* / *particle* division in ARTS.
That would mean including the Liebe rain absorption in the particle
part. It would also affect your nomenclature, since one should then
preferably talk about *ParticleSpecies* rather than
*ScatteringSpecies*.
(And *gas_species* instead of *absorption_species*.)

All the best,

Stefan

On 26 Jan 2021, at 22:10, Simon Pfreundschuh wrote:


Dear Stefan,


I attach the description of the new scattering system that you
requested.

I tried to keep it general to avoid getting lost in technicalities.
If
you have

more specific questions please let me know.


Kind regards,


Simon


From: arts_dev.mi-boun...@mailman.rrz.uni-hamburg.de
 on behalf of Stefan
Buehler 
Sent: Monday, January 25, 2021 9:36:33 AM
To: ARTS Developers List
Subject: Simon plans for scattering properties

Dear all,

one thing I took home from the developer meeting on Friday is that I
would like to better understand Simon’s plans for the scattering
properties. We need this to make a good decision on how to proceed
with
the Rayleigh scattering (incorporate it into the existing scattering
data framework, or make a special case

Re: Simon plans for scattering properties

[Stefan Buehler]

A controlfile example would perhaps help, as in the particle scattering 
example in your concept doc.


On 29 Jan 2021, at 8:42, Stefan Buehler wrote:


Hej Simon,

can you help me understand it then, please? I do want to find the best 
solution, not necessarily the quickest. (But simplicity is part of the 
criteria for “best”.)


/Stefan

On 29 Jan 2021, at 7:11, Simon Pfreundschuh wrote:


Dear Stefan,


I guess all I can say is that I am quite confident that you didn't 
properly


understand my proposal, which could quite easily handle the pressure

dependency. Anyhow, it's quite clear that you are searching for a 
quick


solution and I won't be able to provide that. So let's just cut this 
short.



/s




From: Stefan Buehler 
Sent: Thursday, January 28, 2021 5:02:28 PM
To: Simon Pfreundschuh
Cc: ARTS Developers List
Subject: Re: Simon plans for scattering properties

Dear Simon,

thanks for the summary!

I think I understand more or less how this works now. A bit 
unfortunate

that so much information has to be moved around at the controlfile
level. (The copying of grids from one variable to the other, the 
copying
of the scattering data themselves.) Is the idea that you would then 
in
practise store and load directly the ScatteringHabits, in order to 
make

this easier?

On where the Rayleigh scattering fits in: Patrick suggested when we
talked yesterday that perhaps a more logical way to think about this 
is

to distinguish between *gases* and *particles*, rather than between
*absorption* and *scattering*. (Including Rayleigh scattering with 
the

PND system really does not work, as it turns out, as it depends on
pressure.)

Perhaps we should move towards a *gas* / *particle* division in ARTS.
That would mean including the Liebe rain absorption in the particle
part. It would also affect your nomenclature, since one should then
preferably talk about *ParticleSpecies* rather than 
*ScatteringSpecies*.

(And *gas_species* instead of *absorption_species*.)

All the best,

Stefan

On 26 Jan 2021, at 22:10, Simon Pfreundschuh wrote:


Dear Stefan,


I attach the description of the new scattering system that you
requested.

I tried to keep it general to avoid getting lost in technicalities. 
If

you have

more specific questions please let me know.


Kind regards,


Simon


From: arts_dev.mi-boun...@mailman.rrz.uni-hamburg.de
 on behalf of Stefan
Buehler 
Sent: Monday, January 25, 2021 9:36:33 AM
To: ARTS Developers List
Subject: Simon plans for scattering properties

Dear all,

one thing I took home from the developer meeting on Friday is that I
would like to better understand Simon’s plans for the scattering
properties. We need this to make a good decision on how to proceed
with
the Rayleigh scattering (incorporate it into the existing scattering
data framework, or make a special case for this analytical 
scattering

matrix). Simon, can you please summarize your concept briefly?

All the best,

Stefan

Re: Simon plans for scattering properties

[Stefan Buehler]

Hej Simon,

can you help me understand it then, please? I do want to find the best 
solution, not necessarily the quickest. (But simplicity is part of the 
criteria for “best”.)


/Stefan

On 29 Jan 2021, at 7:11, Simon Pfreundschuh wrote:


Dear Stefan,


I guess all I can say is that I am quite confident that you didn't 
properly


understand my proposal, which could quite easily handle the pressure

dependency. Anyhow, it's quite clear that you are searching for a 
quick


solution and I won't be able to provide that. So let's just cut this 
short.



/s




From: Stefan Buehler 
Sent: Thursday, January 28, 2021 5:02:28 PM
To: Simon Pfreundschuh
Cc: ARTS Developers List
Subject: Re: Simon plans for scattering properties

Dear Simon,

thanks for the summary!

I think I understand more or less how this works now. A bit 
unfortunate

that so much information has to be moved around at the controlfile
level. (The copying of grids from one variable to the other, the 
copying

of the scattering data themselves.) Is the idea that you would then in
practise store and load directly the ScatteringHabits, in order to 
make

this easier?

On where the Rayleigh scattering fits in: Patrick suggested when we
talked yesterday that perhaps a more logical way to think about this 
is

to distinguish between *gases* and *particles*, rather than between
*absorption* and *scattering*. (Including Rayleigh scattering with the
PND system really does not work, as it turns out, as it depends on
pressure.)

Perhaps we should move towards a *gas* / *particle* division in ARTS.
That would mean including the Liebe rain absorption in the particle
part. It would also affect your nomenclature, since one should then
preferably talk about *ParticleSpecies* rather than 
*ScatteringSpecies*.

(And *gas_species* instead of *absorption_species*.)

All the best,

Stefan

On 26 Jan 2021, at 22:10, Simon Pfreundschuh wrote:


Dear Stefan,


I attach the description of the new scattering system that you
requested.

I tried to keep it general to avoid getting lost in technicalities. 
If

you have

more specific questions please let me know.


Kind regards,


Simon


From: arts_dev.mi-boun...@mailman.rrz.uni-hamburg.de
 on behalf of Stefan
Buehler 
Sent: Monday, January 25, 2021 9:36:33 AM
To: ARTS Developers List
Subject: Simon plans for scattering properties

Dear all,

one thing I took home from the developer meeting on Friday is that I
would like to better understand Simon’s plans for the scattering
properties. We need this to make a good decision on how to proceed
with
the Rayleigh scattering (incorporate it into the existing scattering
data framework, or make a special case for this analytical scattering
matrix). Simon, can you please summarize your concept briefly?

All the best,

Stefan

Re: Simon plans for scattering properties

[Stefan Buehler]

Dear Simon,

thanks for the summary!

I think I understand more or less how this works now. A bit unfortunate 
that so much information has to be moved around at the controlfile 
level. (The copying of grids from one variable to the other, the copying 
of the scattering data themselves.) Is the idea that you would then in 
practise store and load directly the ScatteringHabits, in order to make 
this easier?


On where the Rayleigh scattering fits in: Patrick suggested when we 
talked yesterday that perhaps a more logical way to think about this is 
to distinguish between *gases* and *particles*, rather than between 
*absorption* and *scattering*. (Including Rayleigh scattering with the 
PND system really does not work, as it turns out, as it depends on 
pressure.)


Perhaps we should move towards a *gas* / *particle* division in ARTS. 
That would mean including the Liebe rain absorption in the particle 
part. It would also affect your nomenclature, since one should then 
preferably talk about *ParticleSpecies* rather than *ScatteringSpecies*. 
(And *gas_species* instead of *absorption_species*.)


All the best,

Stefan

On 26 Jan 2021, at 22:10, Simon Pfreundschuh wrote:


Dear Stefan,


I attach the description of the new scattering system that you 
requested.


I tried to keep it general to avoid getting lost in technicalities. If 
you have


more specific questions please let me know.


Kind regards,


Simon


From: arts_dev.mi-boun...@mailman.rrz.uni-hamburg.de 
 on behalf of Stefan 
Buehler 

Sent: Monday, January 25, 2021 9:36:33 AM
To: ARTS Developers List
Subject: Simon plans for scattering properties

Dear all,

one thing I took home from the developer meeting on Friday is that I
would like to better understand Simon’s plans for the scattering
properties. We need this to make a good decision on how to proceed 
with

the Rayleigh scattering (incorporate it into the existing scattering
data framework, or make a special case for this analytical scattering
matrix). Simon, can you please summarize your concept briefly?

All the best,

Stefan

Simon plans for scattering properties

[Stefan Buehler]

Dear all,

one thing I took home from the developer meeting on Friday is that I 
would like to better understand Simon’s plans for the scattering 
properties. We need this to make a good decision on how to proceed with 
the Rayleigh scattering (incorporate it into the existing scattering 
data framework, or make a special case for this analytical scattering 
matrix). Simon, can you please summarize your concept briefly?


All the best,

Stefan

New Wang Book

[Stefan Buehler]

Dear ARTS developers,

I got the pdf of his new book from Pao Wang. There is a lot of 
interesting stuff about ice particles shapes and their fall behaviour:


https://www.dropbox.com/s/k5u8j40csr1kfr8/Wang_PK_Motions_of_Ice_Hydrometeors_2021.pdf?dl=0

He wrote it is ok to share among friends, so I thought of you. But 
please do not distribute too widely, so that they can also sell the 
book.


Best wishes, especially for the new year!

Stefan

Re: Tweet von HITRAN auf Twitter

[Stefan Buehler]

Sorry, link was somehow messed up. Here is the right one:
https://twitter.com/hitran/status/1338929277128077313?s=20

It’s to a poster about the new CO2 line shape parameterisation.

/Stefan

On 16 Dec 2020, at 9:49, Stefan Buehler wrote:




HITRAN
⁦‪@hitran‬⁩


Check out (Dec 16th) the #AGU2020 poster by ⁦‪@Robby22413232‬⁩ 
about the new line shape parameterization of the CO2 transitions in 
HITRAN2020

…20fallmeeting-agu.ipostersessions.com/Default.aspx?s…

15.12.20, 20:29



Die Twitter App downloaden

Tweet von HITRAN auf Twitter

[Stefan Buehler]

HITRAN
⁦‪@hitran‬⁩


Check out (Dec 16th) the #AGU2020 poster by ⁦‪@Robby22413232‬⁩ 
about the new line shape parameterization of the CO2 transitions in 
HITRAN2020

…20fallmeeting-agu.ipostersessions.com/Default.aspx?s…

15.12.20, 20:29



Die Twitter App downloaden

[arts-dev] ARTS Videomeeting

[Stefan Buehler]

Dear ARTS friends,

there is an ARTS meeting in the calendar today. However, should we 
perhaps skip it? My reason is egoistic, I have a too full todo list for 
today. Also, Oliver is on vacation, so we would be a bit reduced anyhow.


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

Re: [arts-dev] ARTS control file syntax highlighting for Visual Studio Code

[Stefan Buehler]

Dear Stuart,

that’s great, thanks!

All the best,

Stefan

On 2 Jun 2020, at 11:52, Fox, Stuart wrote:


Hi ARTS developers,

I hope you are all well. Since next week was supposed to be the ARTS 
workshop and I had some spare time when I was on holiday last week I 
decided to develop syntax highlighting for ARTS control files in my 
favourite editor, VS Code. I thought I'd share in case it is of use to 
anyone else - I believe it may also be possible to use it with any 
other editor that can use TextMate grammars. It can be found on GitHub 
(https://github.com/stuartfox/arts-control-lang ) and just needs to be 
downloaded to your .vscode/extensions directory.


The list of keywords is generated from what is available in the pyarts 
Workspace and can be updated using the supplied process_template.py 
script in the top-level folder (requires python, pyarts and jinja2).


I'm happy for this to be bundled with ARTS alongside the vim syntax 
highlighting script,


Stuart
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] Fwd: Workshop on the development of a new open

[Stefan Buehler]

Dear all,

perhaps this workshop is of interest to some of you.

Best wishes,

Stefan

> Begin forwarded message:
> 
> From: Yves Govaerts 
> Subject: Workshop on the development of a new open
> Date: 2. October 2019 at 16:46:00 CEST
> To: stefan.bueh...@uni-hamburg.de
> 
> Dear Stefan,
> 
> The Joint Resaerch Centre of the European Commission is organising a workshop 
> on the development of a new open-source 3D radiative transfer model based on 
> a state-of-the-art Monte Carlo ray tracing method to support Copernicus 
> CalVal activities. This workshop might be of interest to you or your 
> colleagues.
> 
> The announcement letter is still accessible here 
> 
>  (as well as the provisional agenda).
> 
> Registration is still open, until November 5th 2019. To register, send an 
> email to n...@eradiate.eu ! As the number of 
> participants is limited, I would therefore encourage you to register as soon 
> as possible should you be interested to participate to this workshop.
> 
> I hope to see you in Ispra. Do not hesitate to send an email to il to 
> n...@eradiate.eu  should you have any questions on 
> this workshop.
> 
> Kind regards,
> 
> Yves Govaerts
> _
> Consultancy in remote sensing and radiation transfer
> 
> Email: yves.govae...@rayference.eu
> URL: rayference.eu
> URL: http://be.linkedin.com/in/yvesgovaerts
> Phone mobile   : +32 487 39 85 54
> 

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] ARTS scattering database interfaces

[Stefan Buehler]

Dear all,

I started with Zenodo yesterday for another project, and it was very pleasant 
to use actually. So I would suggest to put updates also there, it supports this 
very well. (It automatically generates a special DOI that always points to the 
latest version.) Then on the ARTS webpage just refer to Zenodo.

Best wishes,

Stefan

> On 16. Aug 2019, at 11:33, Oliver Lemke  wrote:
> 
> Hi Robin,
> 
> We removed the link to the ftp server from the webpage once the database was 
> published on Zenodo.
> 
> Our FTP server contains the same version as Zenodo anyway:
> 
> ftp://ftp-projects.cen.uni-hamburg.de/arts/ArtsScatDbase/
> 
> Once there are updates available which are not published on Zenodo, we can of 
> course put the link back.
> 
> Cheers,
> Oliver
> 
> 
>> On 16 Aug 2019, at 10:57, Robin Nils Ekelund  
>> wrote:
>> 
>> Hi Stuart,
>> 
>> Thanks for your input and sorry for the late reply, just got back to the 
>> office. 
>> 
>> As Jana  mentioned, most of us use the Matlab interface, hence we haven't 
>> detected this specific issue so far.
>> 
>> Apart from the Zenodo repository, we have one on a ftp-server in Hamburg. I 
>> just checked the ARTS website and found that it's not linked anywhere yet. 
>> Currently it doesn't matter, because there's is currently no newer version 
>> than the Zenodo one yet anyway.
>> 
>> I'll have a look at your changes Stuart and make sure that those are 
>> available in a new version, accessible from the ARTS homepage. I'm no Python 
>> expert, but I have others I can consult.
>> 
>> Best regards,
>> Robin Ekelund
>> PhD Student   
>> Department of Space, Earth and Environment
>> +46(0)31 772 17 66
>> robin.ekel...@chalmers.se
>> 
>> Chalmers University of Technology
>> Hörsalsvägen 9/11
>> SE-412 96 Göteborg, Sweden
>> www.chalmers.se
>> 
>> 
>> 
>> From: arts_dev.mi-boun...@mailman.rrz.uni-hamburg.de 
>>  on behalf of Jana Mendrok 
>> 
>> Sent: Wednesday, August 14, 2019 12:44 PM
>> To: arts_dev.mi@lists.uni-hamburg.de
>> Cc: Fox, Stuart
>> Subject: Re: [arts-dev] ARTS scattering database interfaces
>> 
>> Hi Stuart,
>> 
>> I guess, it's me to blame here. I did some testing, but obviously not 
>> exhaustive (enough) ;)
>> Maybe it went unnoticed since there is a also matlab version of this, and 
>> maybe everyone who applied the method so far has used matlab. (at least 
>> Patrick. Who surely used the interpolation routine. But very likely in 
>> matlab.)
>> 
>> Back when we developed this, we had an internal repository, which likely 
>> still exists, but I don't think there is a semi-public one like for ARTS and 
>> other ARTS-related tools. Yet. Could be a good thing to have, but that's up 
>> to Patrick and /or Stefan to decide and initiate.
>> Would likely be good, if your changes are at least put into the internal 
>> repository. But I have to leave that to others of the ARTS-DB project group.
>> 
>> Best wishes,
>> Jana
>> 
>> On Fri, Aug 9, 2019 at 11:10 AM Fox, Stuart  
>> wrote:
>> Hi developers,
>> 
>> I’ve been trying to use the Python assp methods (downloaded from the Zenodo 
>> link) to work with some single scattering data. Specifically, I have been 
>> trying to use assp.assp_interp_size to interpolate some optical properties 
>> onto a common size grid. However, there seems to be a number of bugs and 
>> typos in the code which mean that it doesn’t run.
>> 
>> I think I’ve fixed the code so that it “works” (attached). However, I’m 
>> curious to know if anyone has actually used this method before, and if there 
>> are any potential pitfalls I should be aware of? Is there a repository 
>> anywhere for the database interfaces for up-to-date versions etc?
>> 
>> I also had to make some changes to typhon to get things running – see 
>> https://github.com/atmtools/typhon/pull/308
>> 
>> Cheers,
>> 
>> Stuart
>> 
>> Dr Stuart Fox  Radiation Research Manager
>> Met Office FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom
>> Tel: +44 (0) 330 135 2480  Fax: +44 (0)1392 885681
>> Email: stuart@metoffice.gov.uk  Website: www.metoffice.gov.uk 
>> See our guide to climate change at 
>> http://www.metoffice.gov.uk/climate-change/guide/
>> 
>> ___
>> arts_dev.mi mailing list
>> arts_dev.mi@lists.uni-hamburg.de
>> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
>> 
>> 
>> -- 
>> =
>> Jana Mendrok, Ph.D.
>> Deutscher Wetterdienst
>> Frankfurter Str. 135
>> 63067 Offenbach am Main, Germany
>> 
>> Email: jana.mend...@dwd.de
>> Phone : +49 (0)69 8062 3139
>> =
>> ___
>> arts_dev.mi mailing list
>> arts_dev.mi@lists.uni-hamburg.de
>> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
> 
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> 

[arts-dev] Fwd: [Members.cen] [mpicen] Reminder: Summer School EaSyMS 2019

[Stefan Buehler]

Perhaps of interest for someone?Best wishes,StefanBegin forwarded message:From: "Imprs, Office" Subject: [Members.cen] [mpicen] Reminder: Summer School EaSyMS 2019Date: 24. June 2019 at 09:51:28 CESTTo: "Imprs, Office" Reminder – Reminder – Reminder The International Max Planck Research School (IMPRS) of the Max Planck Institute for Meteorology in Hamburg, Germany, invites for its annual Earth System Modelling School (EaSyMS 2019). EaSyMS 2019 is offered as a 1-week event in Hamburg.  Attached you find the preliminary agenda. What is offered?The school introduces to the fundamental processes and dynamics of the natural Earth system. The module includes lectures on the different geophysical and biogeochemical Earth system components (atmosphere, ocean, land) and on their representation in the Max Planck Institute Earth System Model (MPI-ESM). Using the super-computing resources of the German Climate Computing Center (DKRZ), participants will employ MPI-ESM in shock experiments designed to demonstrate the complexity of interactions in the Earth system. The main part of the school is devoted to the analysis of the simulation results in ‘hands on sessions’. Here, the participants will develop their own understanding of the simulation results guided by hypotheses for simulation outcome formulated in group work in advance. They will present their results for discussion with all participants and tutors in a final seminar. Who is addressed?This summer school module of IMPRS-ESM aims at early career scientists (advanced MSc candidates, PhD candidates, early Postdocs) with a strong background in Geo- or Earth system sciences (including physics and mathematics). Participants should possess at least moderate scientific computing and programming skills. Requirements:* CV* Short motivational statement (200–250 words, preferably as email text)* Certificate of completed study program (bachelor's/master's degree or equivalent)* Records with grade point average (GPA) (transcribed if not in German or English)* Language certificate or other proof demonstrating your proficiency in spoken English Please send applications until June 30, 2019, electronically to office.im...@mpimet.mpg.de. When?Monday, September 16 to Friday, September 20, 2019 Where?Universität HamburgBundesstrasse 55GEOMATIKUM building15th floor, seminar room 1528 (for talks) and terminal rooms G1536 a-c (for ‘hands on’) Further information:The overall course duration is scheduled for roughly 6 * 8 hours. IMPRS-ESM doctoral candidates will earn 2 IMPRS credit points for successful participation. There are no fees involved. Board & lodging need to be organized individually by participants. Best regards,The EaSyMS team --Max Planck Institute for MeteorologyOffice IMPRS-ESM Michaela BornAssistant Coordinator International Max Planck Research School (IMPRS-ESM)Assistant Coordinator HD(CP)2Bundesstr. 53, 20146 Hamburg - Germany phone: +49 (0) 40 41173 - 154 / fax: +49 (0) 40 41173 - 366www.imprs-esm.mpimet.mpg.de / hdcp2.eu / www.mpimet.mpg.de 

EaSyMS.2019.Agenda_v-29-05-12.pdf
Description: Adobe PDF document
___Members.cen mailing listmembers@mailman.rrz.uni-hamburg.dehttps://mailman.rrz.uni-hamburg.de/mailman/listinfo/members.cen

smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] Non-fractional grid positions

[Stefan Buehler]

Dear Patrick,

an interesting mail!

Oliver and me both pondered your questions, and now had a brief discussion. We 
think this kind of change is possible in principle.

Suggestions:

1. Hard to do this automatically, and perhaps dangerous. Perhaps we could add 
the threshhold for considering a new point to be exactly on an old grid point 
as a new argument to gridpos? With a default of zero.

2. The awkward and potentially inefficient “tr.nonfrac?1:2” expressions in the 
loop indices could be avoided by not using a bool like nonfrac, but instead 
simply the loop dimension, 1 or 2. The standard value of 2 would give the old 
behaviour, the value 1 the new “nonfrac” case. Your piece of code would be:

tia = 0;
for ( Index r=0; r On 15. Mar 2019, at 08:26, Patrick Eriksson  
> wrote:
> 
> Hi Stefan, Oliver and other interested in this long email,
> 
> I just made a commit where I try to fix things to make retrievals using grids 
> having length 1 possible. This is very handy in some cases, but causes 
> problems with the interpolation inside arts. For the moment I have solved 
> this by special functions, and this generated quite a bit of code.
> 
> But it could in fact be solved in a general manner. And then also fix other 
> things.
> 
> For running OEM the issue of concern appears when mapping the x vector back 
> to arts' variables. If we use 3D and a length-1 pressure retrieval grid as 
> example, then we end up with a situation that we want to interpolate a 
> Tensor3 having size X(1,nlat,nlon)
> X can be a scaling factor for H2O as indicated in my ChangeLog message
> 
> In the calculation of the Jacobian, I use the grid_pos system to map data 
> from line-of-sights to the retrieval grids, and I once made some function 
> that gives a correct grid position for length-1 retrieval grids. That is, the 
> grid position is set to
> 0 0 1
> It works in fact to calculate interpolation weights for this case.
> 
> On the other hand, you can not apply the interp functions, as these functions 
> always include idx+1, even if fd[0]=0. That is, there is a blind summation 
> for the values inside the grid range, even if some values will get weight 0. 
> My new functions could be removed if the interp functions noticed when it is 
> unnecessary to involve idx+1.
> 
> This would also solve:
> 
> Now it is not possible to set the grid position to the end grid point. That 
> is,
> 
> n-1 0 1
> 
> as idx+1 is then an invalid index. This generated extra code in the ppath 
> part. For basically all observations there is a ppath point exactly at the 
> uppermost pressure level.
> 
> Quite a lot of our interpolations could be avoided. As retrieval grids 
> normally are sub-sets of the forward model grids (and is the recommended 
> choice for numerical accuracy), there is a lot of interpolation that in fact 
> is not interpolation (i.e. points of new and old grid are the same). And is 
> this not also the case for interpolation of absorption lookup tables? The 
> normal case should be that the pressure grid of the lookup table equals 
> p_grid. As we here apply polynomial interpolation, a lot of calculations 
> could be saved by identifying when fd[0]=0. (or is there special code for 
> abs_lookup?)
> 
> 
> The question is how to add this without making the general interpolation 
> slower. I assume that a boolean in the grid_pos structure could help, that is 
> true if fd[0] can be treated to be exactly zero. If we call this new field 
> nonfrac, the green 2D interpolation could like this
> 
> tia = 0;
> for ( Index r=0; r for ( Index c=0; c  {
>   tia += a.get(tr.idx+r,tc.idx+c) * itw.get(ir,ic,r*2+c);
>  }
> }
> 
> (cf. interpolation.cc line 2580. Note that I had to add some temporary 
> asserts to make sure that my special code is OK.)
> 
> This has the drawback that r*2+c is more costly than ++iti (as in the present 
> solution), but we could still gain on average. Another option would be that a 
> similar thing is done when calculating the interpolation weights, i.e. the 
> number of weights is smaller when nonfrac is true. The weights should be 
> ordered in such way that ++iti will work. And we should then really gain on 
> average!?
> 
> 
> And now realize that this bool would have saved me a lot of headache in the 
> ppath_step part. There are a lot of checks if fd[0] is effectively zero 
> (which it is for the end points of each step). Introducing the flag would 
> allow me to clean up this.
> 
> 
> What do you say? Comments? Or an even better solution? If you don't follow, 
> ask or let's discuss next Friday.
> 
> Bye,
> 
> Patrick
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de

[arts-dev] Fwd: Laser Photomedicine and Biomedical Optics at the Oregon Medical Laser Center

[Stefan Buehler]

Dear all,

here is a nice Mie scattering code in Python!

Best wishes,

Stefan

> Begin forwarded message:
> 
> From: Bjorn Stevens 
> Subject: Laser Photomedicine and Biomedical Optics at the Oregon Medical 
> Laser Center
> Date: 12. February 2019 at 23:16:15 CET
> To: Stefan Buehler 
> 
> Dear Stefan,
> 
> here is the link to the site where I get the Mie Code:
> 
>> https://omlc.org/index.html <https://omlc.org/index.html>
> 
> 
> cheers, Bjorn
> 
> --
> https://www.mpimet.mpg.de/en/staff/bjorn-stevens/ 
> <https://www.mpimet.mpg.de/en/staff/bjorn-stevens/>



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] Fwd: ARTS user

[Stefan Buehler]

Dear all,

is anyone familiar with this?

Best wishes,

Stefan

> Begin forwarded message:
> 
> From: "良亮" 
> Subject: 回复： ARTS user
> Date: 29. June 2018 at 13:15:48 CEST
> To: "stefan.buehler" 
> 
> Dear Mr. Buehler
> Thank you for your reply.
> 
> Yes, i want a benchmark result which simulate the reflection of rain cloud or 
> whatever that ARTS can handle. For passive radiation, the  widely-used 
> example is raining cloud box at 19.4 GHz(see: Microwave radiative transfer 
> intercomparison study for 3-D dichroic media,2006), which i get the similar 
> result by using modified program. My application is to simulation active 
> radiation ,but hard to find a example like above.
> 
> I use the latest version 2.2.64. I change the coordinate system to 
> rectangular coordinate and use Monte Carlo function directly. Changing ARTS 
> from linux to windows is not so hard. Only some c++ head file and file 
> addressing is different.
> 
> Yours sincerely
> Alfred xu
> 
> 
> -- 原始邮件 --
> 发件人: "stefan.buehler";
> 发送时间: 2018年6月29日(星期五) 下午5:47
> 收件人: "良亮";
> 主题: Re: ARTS user
> 
> Dear Alfred,
> 
> nice to hear that you are using ARTS.
> 
> Is it specific data from a specific paper that you want?
> 
> Which version of ARTS have you used? Do you think your modifications may be 
> useful for other (Windows) users?
> 
> Best wishes,
> 
> Stefan
> 
> > On 29. Jun 2018, at 09:44, 良亮  wrote:
> > 
> > Dear Mr. Buehler
> >
> >I'm a student from South-east university in china. I have studied 
> > ARTS for several months and done some changes to this software package. I 
> > managed to run ARTS under Windows and added a transmitter as microwave 
> > source to simulate the reflection. However, I found it is difficult to 
> > prove the validity of reflective simulation because of the lack of example 
> > and data from paper. Could you help me where can i get the data?
> > 
> > Yours sincerely
> > Alfred xu
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] New general ARTS Paper

[Stefan Buehler]

Hello ARTS users,

I’m happy to announce that our new ARTS model description paper is published. 
For the twitter users:
https://twitter.com/CENunihh/status/987275165938716672

If you use twitter, you would do me a great favour if you could like or retweet 
this.

If you don’t and you just want the article, you can also find it on 
http://www.radiativetransfer.org, or directly at the journal GMD 
(https://www.geosci-model-dev.net/11/1537/2018/).

Best wishes,

Stefan



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] Transit radius

[Stefan Buehler]

Dear all,

here is an ARTS challenge, not strictly important right now, but for my own 
curiosity. Probably mostly to Patrick, but perhaps interesting also for others.

For exoplanet research, one observation technique provides the planet's transit 
radius, that is, the tangent radius where the optical depth of the limb path is 
one.

Can we generate this with ARTS? The simple-minded way I can come up with is to 
do a limb simulation and store opacity for each pencil-beam, along with its 
tangent altitude. Then interpolate to find the tangent altitude for which the 
opacity along the limb path is one.

Is there a smarter way?

And, for the way I outlined, what is the currently recommended way to get out 
tangent altitude and opacity along the los? 

If it is easy to generate, I feel tempted to include a “transit radius” view to 
the nadir spectrum figure in the paper.

Best wishes,

Stefan



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] Retrieval units and transformations

[Stefan Buehler]

Dear Patrick,

I think this is a move in the right direction. Good to have a clear strategy, 
otherwise the complexity will quickly get out of control.

Cheers,

Stefan

> On 3. Dec 2017, at 13:52, Patrick Eriksson  
> wrote:
> 
> Hi Simon, Richard and all,
> 
> I started to think about how to allow a log10 retrieval "unit" for scattering 
> quantities. As often happens, this ended with that I want to make a general 
> cleaning and reorganisation.
> 
> My idea is to move towards a more clear distinction between unit and 
> transformations. In addition, we have to deal with two types of 
> transformations, linear and non-linear. I think these three shall be applied 
> in the order: unit, non-linear and linear.
> 
> Comments:
> 
> unit: This would now just be pure unit changes, such as "nd" (number 
> density). Later I would also like to allow relative and specific humidity for 
> H2O. We could also allow "C" for temperature ...
> 
> (Units changes will be specific for each retrieval quantity, while 
> transformations shoul be implemented in a general manner.)
> 
> Non-lin transformations: I would like to remove the "logrel" option (now an 
> unit option). And instead generally introduce "log" and log10" (without 
> ruling out to add more transformations, such as tanh+1?)
> 
> Linear transformations: As already introduced by Simon.
> 
> The unit part will be handled by the iy-methods. For the transformations I 
> suggest to extend the scope of present jacobianTransform (as well as merging 
> it with jacobianAdjustAfterIteration, that handles a rescaling for "rel" 
> necessary for iterative OEM). 
> 
> 
> All: Comments? Something that I have missed?
> 
> 
> Richard: The handling of units seems a bit messy to me. The function 
> dxdvmrscf is applied in get_ppath_pmat_and_tmat, but only if from_propmat. 
> dxdvmrscf is also applied in adapt_stepwise_partial_derivatives. This 
> confuses me, but could be an heritage of my old code.
> Would it not be simpler if the core code just operates with ARTS default 
> unit, i.e. vmr for abs species? And then the conversion is done only on the 
> final jacobian values (along the ppath). This should be a general function, 
> called towards the end of all iy-methods providing jacobians.
> As far as I can see that should work, and should give cleaner code. Agree? Or 
> have I missed something?
> 
> Bye,
> 
> Patrick
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] Fwd: [arts-users] Including clouds from the Chevallier_91L datasets to radio link simulation

[Stefan Buehler]

Dear all,

does anyone want to reply to Sampo?

Best wishes,

Stefan

> Begin forwarded message:
> 
> From: Sampo Salo 
> Subject: [arts-users] Including clouds from the Chevallier_91L datasets to 
> radio link simulation
> Date: 26. October 2017 at 11:07:45 GMT+2
> To: arts_users...@lists.uni-hamburg.de
> 
> Hi all,
> 
> I have a slightly modified version of the link budget simulation 
> "DemoLinkBudget" provided in the "planetary toolbox". I want to add clouds 
> and rain to this simulation using the Chevallier_91L datasets that I can find 
> in the "control files".
> 
> I _think_ what I would like to do is as follows:
> 
> 1. I want to generate particle number density fields from the Chevallier_91L 
> data which is in plain mass densities (kg/m3 for clouds and kg/m2/s for rain) 
> in a corresponding pressure grid.
> 
> 2. Then I want to interpolate/add these pnd fields in a cloud box that 
> corresponds to the pressure grid that I already have generated in my existing 
> simulation.
> 
> Could anyone here help me to find the correct way to add clouds in my 
> simulation? I have been thinking and thinking about this but I can't find the 
> way to do this.
> 
> Regards,
> Sampo
> ___
> arts_users.mi mailing list
> arts_users...@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] Problem with line absorption in ARTS

[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

smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] Problem with line absorption in ARTS

[Stefan Buehler]

Dear Stuart, dear Richard,

Stuart, thanks for finding and reporting this. This is clearly a bug, due to an 
oversight of mine at the time. For mirror lines, the shift should be such that 
they continue to be at the mirror frequency of the original line. So, if the 
original line shifts to higher frequency, then the mirror line has to shift to 
more negative frequencies.

I have committed a bug fix around the code line that Richard has pointed out, 
since I don’t see a good reason not to fix this.

Richard, perhaps we should follow something like your suggestion 2 in the 
longer run. But Mirrored Lorentz alone would not solve the problem, would it, 
since we need something that transitions in a good way to a Voigt for low 
pressure. Can the HTP profile account for mirror lines? Then that would be the 
best long term solution.

Stuart, could you please test whether the new version fixes the problem?

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 calculations go on as usual.  
> So the addition of pressure shift is not handled correctly.  (It even slows 
> some functions down because we have to apply abs(F0), but this was not 
> considered in regards to the shifting.)
> 
> Two possible solutions exists:
> 1) Change so F0 in line 1350 of absorption.cc has the absolute value applied 
> to it before the shift and is then multiplied by its actual sign.
> 
> 2) Remove the mirrored lines function and enforce F0>0, and tell people to 
> use the existing "Mirrored Lorentz" instead when they want to use the 
> transformation lineshape.
> 
> Option 2 means that all simulations will be slightly faster because it 
> reduces the number of calculations and we an remove some existing abs(F0) 
> complications.  Option 1 means people do not have to change controlfiles but 
> it makes all code slightly slower.  I argue we go with option 2.  The present 
> implementation of how we deal with the pressure shift is not really 
> compatible with HTP, so it will have to change at some point soon anyways.
> 
> What do others on the developer list say?  
> 
> With hope,
> //Richard
> 
> 2017-10-13 15:07 GMT+02:00 Fox, Stuart :
> Thanks Richard. The fact that changing to the mirrored Lorentz lineshape 
> solves the problem suggests to me that it is highly likely that the pressure 
> shift is being added in the wrong direction for the mirrored lines if using 
> abs_lines_per_speciesAddMirrorLines, hence the positive pressure shift 
> coefficient is shifting the mirror line closer to zero rather than further 
> away.
> 
>  
> 
> I know I’m using an “old” version of ARTS – I’ll get round to updating it 
> 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:01
> To: Fox, Stuart 
> Cc: arts_dev.mi@lists.uni-hamburg.de
> Subject: Re: [arts-dev] Problem with line absorption in ARTS
> 
>  
> 
> 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_speciesAddMirrorLines
> 
>  
> 
> to
> 
>  
> 
> abs_lineshapeDefine(shape="Mirrored Lorentz", forefactor="VVW", cutoff=750e9)
> 
>  
> 
> and you will see the results.  (Or just the original "Lorentz" lineshape-call 
> in your main controlfile.)
> 
>  
> 
> With hope,
> 
> //Richard
> 
>  
> 
> Ps. You are running an old version of arts.  The controlfile was not working 
> without changing the order of calls around.  I attach an updated version.  I 
> also recommend that you set ARTS_DATA_PATH to your arts-xml-data path because 
> this makes life easier (export ARTS_DATA_PATH="PATH-TO-DATA" should do the 
> trick).  
> 
>  
> 
> I might have time to look at the details over the weekend and will get back 
> to you later but I hope the temporary solution is good for now.
> 
>  
> 
> 2017-10-13 14:31 GMT+02:00 Fox, Stuart :
> 
> Hi all,
> 
>  
> 
> I wasn’t sure whether to ask this on arts-user or arts-dev - I’m not sure 
> whether there’s a bug in ARTS or something wrong with my inputs!
> 
>  
> 
> I’m trying to do some clear sky brightness temperature simulations for Earth 
> using water vapour lines from HITRAN-2016. However, I am getting huge (over 
> 20K) differences in brightness temperature for a nadir viewing geometry 
> depending on whether I include the mirror (negative frequency) lines or not. 
> I don’t get the same thing using 

Re: [arts-dev] ARTSCAT-5 as default

[Stefan Buehler]

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
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] ARTS Python Interface

[Stefan Buehler]

Hi Simon,

really great! I look forward to learning more and discussing this in 
Kristineberg.

Stefan

> On 22. Aug 2017, at 16:53, Simon Pfreundschuh 
>  wrote:
> 
> Dear All,
> 
> I just pushed a python interface for ARTS that I have been developing during 
> the last week.
> I wrote it mainly to simplify higher-level testing of retrieval code but it 
> turned it to a proper
> interactive interface which provides almost all functionality of a standard 
> controlfile except
> defining agendas.
> 
> I put together a short example highlighting the main features of the 
> interface:
> 
> http://spfrnd.de/posts/2017-08-21-arts-python.html
> 
> However, I saw that I broke the typhon Hudson build. This is because 
> importing the new modules
> fails if the module can't find the arts_api.so contained in ARTS, but I will 
> see what can be done
> about this.
> 
> Cheers,
> 
> Simon
> 
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] About "abs_coefCalcFromXsec"

[Stefan Buehler]

Dear Xiaoying,

as Jana wrote, this does not work at the moment. However, by coincidence, we 
are actually working on that right now. If all goes well, it may be usable by 
the end of the year.

Best regards,

Stefan

> On 13. Jul 2017, at 15:46, Jana Mendrok  wrote:
> 
> Dear Xiaoying,
> 
> there is no way in ARTS (yet?) to use HITRAN absorption cross sections 
> (except for collission-induced continuum absorption. but that's obviously not 
> what you are after.). sorry.
> 
> Best wishes,
> Jana
> 
> On Thu, Jul 13, 2017 at 3:28 PM,  wrote:
> Dear Sir:
> 
>  
> 
> I have some questions about ARTS again.
> 
>  
> 
> Some species (O3 H2O CO CH4 ……) can read spectral lines from line by line 
> file, such as Hitran2012.par. However, at the same time, I want to calculate 
> absorption coefficients from
> 
> absorption cross-sections for some species, such as CCl4, F11…….
> 
>  
> 
> From the user guide, I think the ‘abs_coefCalcFromXsec ‘ may do my job.  But 
> I still have no idea how to apply the method of abs_coefCalcFromXsec?  How to 
> describe the species which will calculate absorption coefficients from 
> absorption cross-sections?  Would you please help me out? I really appreciate 
> your help.
> 
>  
> 
> Best regards!
> 
>  
> 
>  
> 
> Yours sincerely.
> 
>  
> 
> Xiaoying Li
> 
> 
> 
> --
> 
> Li Xiaoying 
> 
> Associate Professor
> 
> Institute of Remote Sesing and Digital Earth, CAS
> 
> State Key Laboratory of Remote Sensing Science
> 
> P.O.Box9718,Beijing 100101,China 
> 
>  
> 
> 
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
> 
> 
> 
> 
> -- 
> =
> Jana Mendrok, Ph.D. (Researcher)
> Chalmers University of Technology
> Department of Space, Earth and Environment
> SE-412 96 Gothenburg, Sweden
> 
> Email: jana.mend...@chalmers.se
> Phone : +46 (0)31 772 1883
> =
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi



smime.p7s
Description: S/MIME cryptographic signature
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] First computer RT code paper

[Stefan Buehler]

Dear Franz,

thanks for all the great suggestions!

As to the 1952 number, I doubt that programmable computers as we know them were 
readily available in 1952. It really is not totally straightforward to guess 
how early calculations were performed practically. 

Best wishes,

Stefan

> On 26. Apr 2017, at 17:51, Franz Schreier <franz.schre...@dlr.de> wrote:
> 
> Hi Stefan, Dear all,
> 
> when thinking about 'old' radiative transfer computations Lowtran and Fascode 
> immediately comes to my mind.
> In my book shelf I found a Lowtran5 report (1980), that cites
> Selby & McClatchey: Atmospheric Transmittance and Radiance ... Lowtran 2 
> (AFCRL-TR-72-0745)
> Apparently work on RT modeling at (AF)GL has begun already in the sixties or 
> even earlier.
> In fact, I also found
> Ruth P. Liebowitz (GL Historian): Historical Brief GL Atmospheric Propagation 
> Codes for DoD Systems
> In section 2. - The creation of LOWTRAN and FASCODE
> "During the 1960s, AFCRL began to work towards the creation of transmission 
> models. ...
> The early 1960s had seen the creation of band-models such as the Goody and 
> Altschuler models 
> Parallel to this applied effort, AFCRL continued to pursue basic research 
> goals. The infrared
> spectroscopy programs of the 1960s  "
> 
> Ultimately this became Hitran!
> The very first report "AFCRL Atmospheric Absorption Line Parameters 
> Compilation"
> https://www.cfa.harvard.edu/hitran/Download/AFCRL73.pdf
> starts with "About 10 years ago a program was initiated to compile 
> spectroscopic data ... (Gates et al. 1964)" linking to "computed spectra".
> 
> Thomas Trautmann also suggested to remember the work of Plass, Kattawar, 
> Atwater, King, Kaplan etc.
> Some of these old works are also referenced in old reviews, e.g.
> A.J. LaRocca: Methods of Calculating Atmospheric Transmittance and Radiance 
> in the Infrared
> (1975, doi: 10.1109/PROC.1975.9709)
> 
> G.N. Plass: A Method for the Determination of Atmospheric Transmission 
> Functions from Laboratory Absorption Measurements (1952, doi 
> 10.1364/JOSA.42.000677)
> > the calculations become so complicated that accurate results could only be 
> > obtained with the aid of an electronic computor.
> 
> G.N. Plass: Models for Spectral Band Absorption (1958, doi 
> 10.1364/JOSA.48.000690)
> 
> L.D. Gray & R.A. McClatchey: Calculations of Atmospheric Radiation From 4.2 μ 
> to 5 μ
> (1965, doi: 10.1364/AO.4.001624)
> > The present calculations utilize a computer subroutine, due to L. D. Kaplan 
> > and A. R. Curtis,
> 
> M.A. Atwater: Comparison of Numerical Methods for Computing Radiative 
> Temperature Changes in the Atmospheric Boundary Layer 
> (http://dx.doi.org/10.1175/1520-0450(1966)005%3C0824:CONMFC%3E2.0.CO;2)
> [Flux calculations, but "artificial satellites" are mentioned, remote 
> sensing?]
> 
> Ok, guess this is enough for today, with 1952 as the earliest paper.
> 
> Best wishes from Oberpfaffenhofen
> Franz
> 
> 
> On 04/26/2017 11:17 AM, Stefan Buehler wrote:
>> Dear radiative transfer enthusiasts,
>> 
>> here is a challenge for you: What is the earliest paper that describes 
>> remote sensing radiative transfer calculations on an electronic computer?
>> 
>> For energy flux calculations, there is for example the landmark paper by 
>> Manabe and Möller from 1961. Funnily, in these old papers, it is not always 
>> easy to judge whether a computer was used or not, often it is not mentioned 
>> explicitly.
>> 
>> Anyway, now I’m interested not in flux calculations, but in the earliest 
>> paper that describes a forward model computer code for remote sensing. Any 
>> suggestions?
>> 
>> Best wishes,
>> 
>> Stefan
>> 
>> Refs:
>> 
>> MANABE, S. and MÖLLER, F.: ON THE RADIATIVE EQUILIBRIUM AND HEAT BALANCE OF 
>> THE ATMOSPHERE, Monthly Weather Review, 89(12), 503–532, 
>> doi:10.1175/1520-0493(1961)089<0503:OTREAH>2.0.CO;2, 1961..
>> 
> 

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] First computer RT code paper

[Stefan Buehler]

Dear Johannes,

thanks, this is a great paper, it fits very well what I was looking for.

Best wishes,

Stefan

> On 26. Apr 2017, at 12:32, Orphal, Johannes (IMK) <johannes.orp...@kit.edu> 
> wrote:
> 
> Dear all,
>  
> Here is my suggestion (enclosed): Williamson & Houghton, Quarterly Journal of 
> the Royal Meteorological Society, 91, 330-338, 1965
>  
> Citation (last paragraph on page 332):
> "The method which has been adopted consists of finding a water-vapour 
> distribution which would produce the same radiometer signals as those 
> observed. For the purpose of analysis, the atmosphere is divided into layers 
> by a set of horizontal levels at 1 km intervals. The initial assumption is 
> made that the signal measured at the top of the ascent is due to emission 
> from water vapour which is distributed with a constant mixing ratio above 
> that level. The value of mixing-ratio is chosen to provide agreement between 
> the observed signal and that calculated from Eq. (2). The signal at the first 
> level below the top is then considered, and the amount of water vapour in the 
> first 1 km layeris adjusted by an iterative process performed on a computer, 
> until agreement is obtained between the observed and calculated signals. This 
> same procedure is then followed for each subsequent level, and a water-vapour 
> distribution built up layer by layer."
>  
> The “code” is not described in further detail but all the equations are in 
> the paper.
>  
> Best wishes,
>  
> Johannes 
>  
> -Ursprüngliche Nachricht-
> Von: John Burrows [mailto:burr...@iup.physik.uni-bremen.de] 
> Gesendet: Mittwoch, 26. April 2017 12:02
> An: Stefan Buehler
> Cc: ARTS Development List; Robert Pincus; Eli Mlawer; MISHCHENKO, MICHAEL I. 
> (GISS-6110); Klaus Künzi; Clarmann von Clarenau, Thomas (IMK); Justus 
> Notholt; Andreas Macke; Orphal, Johannes (IMK); Franz Schreier; qiang fu
> Betreff: Re: First computer RT code paper
>  
> Good question!
>  
> The publications in the 1930s on the Turing machines and some related were 
> the first about modern computers.
>  
> When was radiative transfer first developed as a concept- Chandrasekhar or 
> before?
>  
> I am interested in the result.
>  
>  
>  
> Sent from my iPhone
>  
>  
> John
>  
> > On 26. Apr 2017, at 11:17, Stefan Buehler <stefan.bueh...@uni-hamburg.de> 
> > wrote:
> > 
> > Dear radiative transfer enthusiasts,
> > 
> > here is a challenge for you: What is the earliest paper that describes 
> > remote sensing radiative transfer calculations on an electronic computer?
> > 
> > For energy flux calculations, there is for example the landmark paper by 
> > Manabe and Möller from 1961. Funnily, in these old papers, it is not always 
> > easy to judge whether a computer was used or not, often it is not mentioned 
> > explicitly.
> > 
> > Anyway, now I’m interested not in flux calculations, but in the earliest 
> > paper that describes a forward model computer code for remote sensing. Any 
> > suggestions?
> > 
> > Best wishes,
> > 
> > Stefan
> > 
> > Refs:
> > 
> > MANABE, S. and MÖLLER, F.: ON THE RADIATIVE EQUILIBRIUM AND HEAT BALANCE OF 
> > THE ATMOSPHERE, Monthly Weather Review, 89(12), 503–532, 
> > doi:10.1175/1520-0493(1961)089<0503:OTREAH>2.0.CO;2, 1961.
>  
> <49709138907_ftp.pdf>

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] First computer RT code paper

[Stefan Buehler]

Dear John,

I would say with K. Schwarzschild, Über das Gleichgewicht der Sonnenatmosphäre, 
1906, where he develops the RTE for a nonscattering atmosphere.

Best wishes,

Stefan

> On 26. Apr 2017, at 12:02, John Burrows <burr...@iup.physik.uni-bremen.de> 
> wrote:
> 
> Good question!
> 
> The publications in the 1930s on the Turing machines and some related were 
> the first about modern computers.
> 
> When was radiative transfer first developed as a concept- Chandrasekhar or 
> before?
> 
> I am interested in the result.
> 
> 
> 
> Sent from my iPhone
> 
> 
> John
> 
>> On 26. Apr 2017, at 11:17, Stefan Buehler <stefan.bueh...@uni-hamburg.de> 
>> wrote:
>> 
>> Dear radiative transfer enthusiasts,
>> 
>> here is a challenge for you: What is the earliest paper that describes 
>> remote sensing radiative transfer calculations on an electronic computer?
>> 
>> For energy flux calculations, there is for example the landmark paper by 
>> Manabe and Möller from 1961. Funnily, in these old papers, it is not always 
>> easy to judge whether a computer was used or not, often it is not mentioned 
>> explicitly.
>> 
>> Anyway, now I’m interested not in flux calculations, but in the earliest 
>> paper that describes a forward model computer code for remote sensing. Any 
>> suggestions?
>> 
>> Best wishes,
>> 
>> Stefan
>> 
>> Refs:
>> 
>> MANABE, S. and MÖLLER, F.: ON THE RADIATIVE EQUILIBRIUM AND HEAT BALANCE OF 
>> THE ATMOSPHERE, Monthly Weather Review, 89(12), 503–532, 
>> doi:10.1175/1520-0493(1961)089<0503:OTREAH>2.0.CO;2, 1961.
> 

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

[arts-dev] First computer RT code paper

[Stefan Buehler]

Dear radiative transfer enthusiasts,

here is a challenge for you: What is the earliest paper that describes remote 
sensing radiative transfer calculations on an electronic computer?

For energy flux calculations, there is for example the landmark paper by Manabe 
and Möller from 1961. Funnily, in these old papers, it is not always easy to 
judge whether a computer was used or not, often it is not mentioned explicitly.

Anyway, now I’m interested not in flux calculations, but in the earliest paper 
that describes a forward model computer code for remote sensing. Any 
suggestions?

Best wishes,

Stefan

Refs:

MANABE, S. and MÖLLER, F.: ON THE RADIATIVE EQUILIBRIUM AND HEAT BALANCE OF THE 
ATMOSPHERE, Monthly Weather Review, 89(12), 503–532, 
doi:10.1175/1520-0493(1961)089<0503:OTREAH>2.0.CO;2, 1961.
___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] MPM89 H2O absorption model

[Stefan Buehler]

Dear Stuart,

it really should be included in continua.arts, I think.

All the best,

Stefan

> On 2 Feb 2017, at 17:30, Fox, Stuart  wrote:
> 
> Hi all,
> 
> Is there a reason why the MPM89 complete H2O absorption model isn't included 
> as an option in continua.arts? As far as I can tell the code for it has been 
> implemented in continua.cc, so all that's needed is to add 
> abs_cont_descriptionAppend(tagname="H2O-MPM89",model="MPM89") to the control 
> file. A quick test seems to show reasonable results, but I'd like to confirm 
> that there's not a good reason why it's not already available!
> 
> Cheers,
> 
> Stuart
> 
> Dr Stuart Fox  Radiation Research Scientist 
> Met Office FitzRoy Road  Exeter  Devon  EX1 3PB  United Kingdom 
> Tel: +44 (0)1392 885197  Fax: +44 (0)1392 885681 
> Email: stuart@metoffice.gov.uk  Website: www.metoffice.gov.uk 
> 
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Re: [arts-dev] Radar Monte Carlo Code

[Stefan Buehler]

Dear Ian,

yes, ok to commit also from my side. (Or we will sort out between Patrick, 
Oliver, and me how to integrate the code you sent.)

This is really great. :-)

Best wishes,

Stefan

> On 22 Dec 2016, at 08:46, Patrick Eriksson  
> wrote:
> 
> Hi Ian,
> 
> A very nice Christmas gift!
> 
> I am on vacation but could not stop myself to take a first look at your 
> additions. Besides MCRadar itself, it's excellent that you have introduced a 
> sensor based treatment of the polarization, that is a very old ToDo for me 
> and presently one of the main shortcomings of ARTS. That stuff should also be 
> incorporated into yCalc.
> 
> Did not expect ppathFromRtePos2 to be used here! That method is a bit of 
> quick hack, and I am happy if it turned out to work sufficiently well for you 
> (I expected much more crashes than 0.001%. Besides being a bit unstable, 
> ppathFromRtePos2 is slow. I assume refraction must be considered for 
> ground-based weather radars, but for other cases this can potentially be 
> handled both much faster and safer.)
> 
> As yCloudRadar was also a quick thing from, I am also curious if you have 
> done any comparisons?
> 
> Anyhow, most important right now is to get this into the repository version. 
> Not clear here if you want an OK from us to commit these additions, or if 
> making svn commits is not possible for you?
> 
> You have a big OK from me (and I assume from all others as well) to commit. 
> This is great stuff and brings ARTS closer to be a complete tool for the 
> microwave region.
> 
> (If we over here have to put this into svn it could take some time as it is 
> holiday times. I have no time until Jan. Anybody else?)
> 
> Cheers,
> 
> Patrick
> 
> 
> 
> On 2016-12-21 21:27, Ian S. Adams wrote:
>> Dear ARTS Developers,
>> 
>> Attached is the Monte Carlo code for solving the radiative transfer
>> equation for a profiling weather radar. In developing the radar module,
>> I expanded the functionality within mc_radar to rotate from the antenna
>> frame to the ARTS reference frame used for radiative transfer
>> calculations. This includes functionality to rotate the polarization
>> basis to (and from for propagation away from the radar) the antenna
>> boresight polarization basis. A README document accompanies the the code
>> further explaining the additions.
>> 
>> Cheers,
>> Ian
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>   *Ian Stuart Adams*
>> 
>>   Electronics Engineer, Remote Sensing Division
>> 
>>   U.S. Naval Research Laboratory
>> 
>>   *T * 202.767.1937   *F * 202.767.7885   *DSN * 297.1937
>> 
>>   www.nrl.navy.mil
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> arts_dev.mi mailing list
>> arts_dev.mi@lists.uni-hamburg.de
>> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
>> 
> ___
> arts_dev.mi mailing list
> arts_dev.mi@lists.uni-hamburg.de
> https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

___
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi