Re: Failing tests

[Oliver Lemke]

Hi Patrick,

I'm currently working on the conversion of the lookup table to use 
propmat_clearsky_agenda instead of abs_xsec_agenda and also porting the 
remaining abs_xsec_per_speciesAdd* methods to propmat_clearksyAdd*. It should 
be ready within the next two weeks.

> On 22 Sep 2021, at 08:30, Patrick Eriksson  
> wrote:
> 
> Hi again,
> 
> Seems that I have found the reason to some of the failing tests "the hard 
> way". After spending time on some other failing calculations, I have figured 
> out that the default in ARTS gives absorption lookup-tables that miss all 
> lines. For example, TestOdinSMR_1D uses
> 
> Copy(abs_xsec_agenda, abs_xsec_agenda__noCIA)
> 
> This agenda is defined as
> 
> AgendaSet( abs_xsec_agenda__noCIA ){
>  abs_xsec_per_speciesInit
>  abs_xsec_per_speciesAddConts
> }
> 
> No inclusion of lines! Another Odin/SMR test uses
> 
> AgendaSet( abs_xsec_agenda ) {
>  abs_xsec_per_speciesInit
>  abs_xsec_per_speciesAddConts
>  abs_xsec_per_speciesAddLines
> }
> 
> and this works. Both tests generates abs tables.
> 
> I get a message that abs_xsec_per_speciesAddLines is deprecated. But why 
> removed from the defaults for abs_xsec_agenda before the alternative is in 
> place?

I think (@richard correct me if I'm wrong), it was done during the conversion 
of  abs_xsec_per_speciesAddLines to propmat_clearksyAddLines. In that process, 
most controlfiles where converted to only use propmat_clearsky. Calculations 
that require AddConts or AddCIA, which are not converted to propmat_clearsky 
yet, use propmat_clearskyAddXsecAgenda to call abs_xsec_agenda and converts the 
cross sections to absorption coefficients. Since AddLines is already available 
as a propmat_clearsky method, it was removed from the default abs_xsec_agenda 
to not accidentally calculate line absorption twice.

> Anyhow, how shall abs_xsec_agenda be defined to get correct abs tables in 
> v2.5?

For lookup tables the abs_xsec_agenda has to be set explicitly to contain 
abs_xsec_per_speciesAddLines in the controlfile.

As you found, the TestOdinSMR.arts files was adapted for that. Unfortunately, 
it seems that controlfiles that are not part of the default "make check" where 
missed.

Cheers,
Oliver

Re: Correct text encoding for ARTS source code?

[Oliver Lemke]

Hi Stuart,

The Unix `file` command reports it as ISO-8859. If that doesn't work, send me a 
line number with an example of the broken characters, then I can have a closer 
look.

Cheers,
Oliver


> On 21 Sep 2021, at 15:02, Fox, Stuart  wrote:
> 
> Hi arts devs,
> 
> I’m currently working on incorporating v3.5 of the MT-CKD continuum into 
> ARTS, and have a question relating to the “correct” text encoding for the 
> ARTS source files.
> The file I’m working on (legacy_continua.cc) has some non-ASCII characters in 
> the comments, which I think are mostly things like superscripted numbers. 
> What text encoding is used for these? If I open the file in VS Code (which 
> assumes it is UTF-8 encoded by default) they show up as unknown characters, 
> and this particular editor then changes them when the file is saved which 
> leads to lots of undesired diffs. Which encoding should I tell the editor to 
> use for these files to avoid this? It looks to me like it’s probably one of 
> the “Western” encodings, e.g. Windows 1252 or ISO-8859-x , but it would be 
> good to confirm which one I should use!
> 
> Stuart

Default build type switched to Release

[Oliver Lemke]

Hi all,

With the merge of PR #328 [1], the default build type for ARTS is now Release 
mode. That means if you want to compile your ARTS with assertions and debug 
information, you have to pass -DCMAKE_BUILD_TYPE=RelWithDebInfo to cmake when 
you configure ARTS.

Cheers,
Oliver

[1] https://github.com/atmtools/arts/pull/328 

DKIM Test

[Oliver Lemke]

Hi all,

If you are subscribed with a Gmail or Yahoo address to this list and
received this mail, please reply to me (personally, not to the list,
to avoid spam).

This is a test if disabling the subject prefix and body signature
resolves the issue of mails not being delivered from DKIM signed
sources to DKIM verifying recipients.

Cheers,
Oliver

Re: [arts-dev] ARTS Server Maintenance 11.11.2020 [COMPLETE]

[Oliver Lemke]

Hi all,

The server maintenance was completed successfully.

Cheers,
Oliver


> On 10 Nov 2020, at 09:01, Oliver Lemke  wrote:
> 
> Hi all,
> 
> Wednesday morning at 8:00 the ARTS webserver will go down for maintenance 
> work. It needs to be moved to a new virtualization infrastructure. The 
> maintenance is expected to be completed by noon.
> 
> Website and Subversion repository will be unavailable during this time.
> 
> Cheers,
> Oliver
> 



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] ARTS Server Maintenance 11.11.2020

[Oliver Lemke]

Hi all,

Wednesday morning at 8:00 the ARTS webserver will go down for maintenance work. 
It needs to be moved to a new virtualization infrastructure. The maintenance is 
expected to be completed by noon.

Website and Subversion repository will be unavailable during this time.

Cheers,
Oliver



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] ARTS 2.4.0 Release

[Oliver Lemke]

Dear ARTS community,

Today we're happy to announce the release of ARTS 2.4. Since the last release 
in 2014, development has carried on and many new features and improvements have 
found its way into ARTS. Below you find a list of the most important changes.

Links to source code and documentation can be found on our homepage:

https://www.radiativetransfer.org/getarts/#stable

Updated atmlab and arts-xml-data packages are available as well:

https://radiativetransfer.org/tools/

Thanks to all of you who have been using ARTS in the past years for their 
science. We're looking forward to your feedback and contributions.


Key features


- New improved format for line-by-line data
- Non-LTE (pure-rotational non-overlapping, and non-chemical cases)
- Dedicated methods for heating rate calculations
- Basic simulations of radars (both single and multiple scattering)
- Radio link calculations not supported in this version
- Interfaces to DISORT and RT4 scattering solvers
- Jacobian for new quantities:
 - spectroscopic variables
 - particle properties (approximative)
- OEM type inversions inside ARTS
- TELSEM and TESSEM surface models
- PyARTS: Python bindings for ARTS


General
===

- Radiative transfer code (except MC) totally revised, including:
 - Higher consistency between modules
 - Higher calculation efficiency
 - Jacobian of atmospheric variables now fully analytical
- Absorption/LBL revised
 - Support for new lineshapes
 - Performance improvements
- New and extended system for defining particle size distributions
- DOIT improvements
 - Optimized pressure grid
 - Convergence acceleration
 - Optional precalculated first-guess field
- New sensor setup for passband-type, meteorological millimeter
 instruments (sensor_responseMetMM)


Known Issues


- TestSpectroscopy fails on macOS


Stay healthy and enjoy,
The ARTS Developers



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] 2.4 release approaching

[Oliver Lemke]

Hi all,

The 2.4 release is finally (almost) happening. Tomorrow morning (14.10.) I'll 
bump the versions for atmlab, arts-xml-data and arts to 2.4 and package them 
for release.

If there are any last minute fixes you need to get into any of those packages, 
today is your last chance to do so.

Let me know if you see any showstoppers.

Cheers,
Oliver



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] PSDs scheme

[Oliver Lemke]

Hi,

> On 5 Jul 2020, at 06:07, Zeqian Xia  wrote:
> 
> Dear,
> 
> Could you tell me the available two-moment PSDs schemes for ice and snow in 
> the latest ARTS 2.3? I found a clue in the 'scat_species' in the built-in 
> documentation server saying that "For currently possible PSDs see 
> pnd_fieldCalcFromParticleBulkProps", but no specific PSD instruction can be 
> found in the new link.  I once used the  IWC-S2M_M, but it seems to be no 
> longer accessible.

All workspace methods to calculate PSD schemes have a name starting with "psd". 
psdSeifertBeheng06 and psdMilbrandtYau05 are two schemes that support ice and 
snow. Not sure if there are any more, but maybe someone more familiar with PSDs 
can chime in.

> By the way, is it possible to download the previous ARTS 2,3 version? That 
> would be greatly helpful since some of my codes run well in the older one.

You can use 'git checkout COMMIT_ID' in your working copy to go back to any old 
version. You find the COMMIT_ID above each log entry in 'git log'. With 'git 
checkout master' you can get back to the latest version.

> I appreciate your answers in advance. Have a great day!

Cheers,
Oliver



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 control file syntax highlighting for Visual Studio Code

[Oliver Lemke]

Hi Stuart,

This is really cool. Just tried it in VSCode and it works like charm.

I think it would be great to distribute this alongside ARTS. If you don't mind 
please open a PR that adds it to the ARTS tools/ directory.

Thanks for sharing this with the ARTS community.

Cheers,
Oliver


> 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



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 interfaces

[Oliver Lemke]

Hi Stuart,

The linker issue is resolved in the latest version.

Cheers,
Oliver


> On 16 Apr 2020, at 14:31, Fox, Stuart  wrote:
> 
> Yes, that seems to work - builds successfully and passes all standard tests. 
> Thanks!
> 
> -Original Message-----
> From: Oliver Lemke  
> Sent: 16 April 2020 13:01
> To: Fox, Stuart 
> Cc: ARTS Development List 
> Subject: Re: [arts-dev] ARTS/Python interfaces
> 
> 
> Do you set the CMAKE_BUILD_TYPE to Release when you get this error? If so, 
> try to compile with CMAKE_BUILD_TYPE=RelWithDebInfo as a temporary 
> workaround. Does that fix the error for you?
> 
> Cheers,
> Oliver
> 
> 
>> On 16 Apr 2020, at 13:24, Oliver Lemke  wrote:
>> 
>>> However, I can’t actually get the most recent dev-version of ARTS to build 
>>> at all. Linking fails with a bunch of errors along the lines of
>>> libartscore.a(m_absorptionlines.cc.o): In function 
>>> `abs_linesWriteSpeciesSplitXML(my_basic_string const&, 
>>> Array const&, my_basic_string const&, Verbosity 
>>> const&)':
>>> m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void 
>>> WriteXML >(my_basic_string const&, 
>>> Array const&, my_basic_string const&, long const&, 
>>> my_basic_string const&, my_basic_string const&, 
>>> my_basic_string const&, Verbosity const&)'
>>> 
>>> Any ideas what’s wrong?
>> 
>> I think I've seen that error when compiling on one of our servers. I'll try 
>> to reproduce and fix this.
>> 
>> Cheers,
>> Oliver
> 



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 interfaces

[Oliver Lemke]

Do you set the CMAKE_BUILD_TYPE to Release when you get this error? If so, try 
to compile with CMAKE_BUILD_TYPE=RelWithDebInfo as a temporary workaround. Does 
that fix the error for you?

Cheers,
Oliver


> On 16 Apr 2020, at 13:24, Oliver Lemke  wrote:
> 
>> However, I can’t actually get the most recent dev-version of ARTS to build 
>> at all. Linking fails with a bunch of errors along the lines of
>> libartscore.a(m_absorptionlines.cc.o): In function 
>> `abs_linesWriteSpeciesSplitXML(my_basic_string const&, 
>> Array const&, my_basic_string const&, Verbosity 
>> const&)':
>> m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void 
>> WriteXML >(my_basic_string const&, 
>> Array const&, my_basic_string const&, long const&, 
>> my_basic_string const&, my_basic_string const&, 
>> my_basic_string const&, Verbosity const&)'
>> 
>> Any ideas what’s wrong?
> 
> I think I've seen that error when compiling on one of our servers. I'll try 
> to reproduce and fix this.
> 
> Cheers,
> Oliver



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 interfaces

[Oliver Lemke]

Hi Stuart,

> On 9 Apr 2020, at 15:51, Fox, Stuart  wrote:
> 
> Thanks – good news that there hopefully won’t be many modifications to work 
> with pyarts (although I’m not sure I’m looking forward to having to try and 
> work out how to get Python stuff that is fully integrated in ARTS working 
> with our systems here if they need packages that aren’t available in our 
> default installs).

If it's a Linux system, the use of pyarts should be very easy. Thanks to Simon, 
we now provide a version via PyPi with a precompiled ARTS library for Linux. 
Getting it should be as easy as doing:

pip install --user pyarts

No need to even check out the ARTS source code. :-) At least if you don't need 
anything from controlfiles/general.

> However, I can’t actually get the most recent dev-version of ARTS to build at 
> all. Linking fails with a bunch of errors along the lines of
> libartscore.a(m_absorptionlines.cc.o): In function 
> `abs_linesWriteSpeciesSplitXML(my_basic_string const&, 
> Array const&, my_basic_string const&, Verbosity 
> const&)':
> m_absorptionlines.cc:(.text+0x8e95): undefined reference to `void 
> WriteXML >(my_basic_string const&, 
> Array const&, my_basic_string const&, long const&, 
> my_basic_string const&, my_basic_string const&, 
> my_basic_string const&, Verbosity const&)'
>  
> Any ideas what’s wrong?

I think I've seen that error when compiling on one of our servers. I'll try to 
reproduce and fix this.

Cheers,
Oliver


> Stuart
>  
> From: Richard Larsson  
> Sent: 09 April 2020 14:40
> To: Fox, Stuart 
> Cc: arts_dev.mi@lists.uni-hamburg.de
> Subject: Re: [arts-dev] ARTS/Python interfaces
>  
> Hi Stuart,
>  
> The dev-version of ARTS has full support of the workspace methods of typhon.  
> In fact, typhon.arts.workspace is simply pyarts.workspace with some small 
> modifications.  So things should work as they have with typhon just making 
> that replacement in your imports.  If you use other things from typhon, like 
> setting environment data like arts-xml-data paths, I am really not sure how 
> it they work in the future.  I hope we can add that to let pyarts handle it 
> automatically itself.
>  
> I see no reason why typhon should remove the ARTS interface entirely, but 
> they will likely want to change so the version of pyarts from ARTS replaces 
> the "arts" module when things settle down on the ARTS side.  Especially if 
> the two projects start to diverge (e.g., new python features will be added to 
> the ARTS-version, and not to typhon).
>  
> With hope,
> --Richard
>  
> Den tors 9 apr. 2020 kl 14:24 skrev Fox, Stuart :
> Hi developers,
>  
> I’ve just been working on interfacing some Python code with ARTS (basically 
> using ARTS to provide atmospheric radiances for use with the SMRT snow 
> surface microwave model). So far my implementation uses the 
> typhon.arts.workspace functions for the interfacing, but I notice from the 
> recent history on github that there might be some other ARTS/Python work 
> going on at the moment? Does this mean that the typhon method will be 
> deprecated soon? Is there any info/update on what is going on with 
> ARTS/python interfacing?
>  
> Cheers,
>  
> 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



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] 20 Years of ARTS Development

[Oliver Lemke]

Hi all,

20 years ago, on March 11 in 2000, ARTS was born and development started. As a 
little celebration, I put together an animation to compress these 20 years into 
a 3 minute video:

https://youtu.be/rGQDuLs2-5c 

Looking forward to the next 20 years. :-)

Have fun,
Oliver

___
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] Line by line update

[Oliver Lemke]

Hi all,

The major changes described in Richard's previous mail have now been merged 
into the ARTS master branch. As mentioned, we don't expect everything to work 
perfectly right out of the box. Please give the new version a try with your own 
controlfiles and provide us feedback.

There is a branch (before-newlinerecord) available in the GitHub repository 
that points to the ARTS version just before this merge. You can check it out if 
you need to revert your local ARTS version back to the old system.

You can also use the "Files changed" tab in this github diff view[1] to see 
what changes have been made and how the existing controlfiles have been adapted 
to the new system:

[1] https://github.com/atmtools/arts/compare/before-newlinerecord...master 


One amendment to Richard's previous mail concerning iyEmissionStandardParallel:

iyEmissionStandard has been replaced with iyEmissionStandardParallel. 
Therefore, there is no need to change anything related to that in your 
controlfiles. The old version of iyEmissionStandard is currently still 
available under the name iyEmissionStandardSequential, but it is considered 
deprecated and should be removed after further testing.

Cheers,
Oliver


> On 9. Dec 2019, at 09:40, Richard Larsson  wrote:
> 
> Dear ARTS developers,
> 
> The infrastructure for ARTS line-by-line data will change significantly with 
> an upcoming update to the development version of ARTS.  Your simulations will 
> be broken before you adapt to the new infrastructure.  I will use this email 
> to explain what updates are required to continue your simulations as before.  
> I will first justify the necessity of the update.  To follow this in more 
> detail, please see the discussion between various people involved in the 
> update on the github page.  The discussion is named "newlinerecord #70".  It 
> might be particularly useful to check how different *.arts files has had to 
> be updated.
> 
> Background
> 
> In the past few years the line-by-line data has grown massively.  The reason 
> for this is the necessity to include quantum numbers to do some of the more 
> advanced calculations, and the change from only allowing pure Voigt 
> calculations in air, to allow any species mixture to make up the broadening 
> bath, to allow line mixing computations, and to allow other beyond-Voigt line 
> shapes.
> 
> The main problem with the old system of keeping all data on a line-by-line 
> basis was that a lot of this data was shared between several lines.  In 
> total, we stored close to 1 kB of data per absorption line that could 
> basically be shared between hundreds or thousands of other lines.  This was 
> about half of the absorption line memory footprint.  Another problem was that 
> each line could have their own reference temperature, their own mass, their 
> own pressure broadening scheme, their own cutoff frequencies, their own line 
> normalization, and so on.  Thus every individual line must have many of their 
> parameters computed from scratch even though it was likely that much of the 
> information of the previous absorption line could just be copied.
> 
> The new system intends to keep all the metadata about how the computations 
> are performed separate from the pure line-by-line data.  This will create 
> more robust absorption line catalogs, since the meta data about the 
> computations are stored with the original data itself.
> 
> Controlfiles
> 
> The problem for the controlfiles are however quite large.  There are several 
> workspace variables that have been removed: abs_lineshape, 
> abs_species_per_band, lm_p_lim, and zeeman_linerecord_precalc. These are now 
> dealt with by the new absorption line format itself.  For lm_p_lim, this 
> means that the entire band has to have a singular pressure limit.  For 
> abs_lineshape, this means that the entire band has to share the same line 
> normalization, line cutoff, and line shape calculator.  There are methods to 
> set these globally on a loaded catalog, either for a specific 
> ArrayOfSpeciesTag or for the entire line catalog.  The others two just became 
> superfluous during the changes being made to the line catalog.
> 
> There has been one new workspace variables added: lbl_checked.  This variable 
> has to be set to run any of the line-by-line calculations, i.e., *Zeeman and 
> *AddLines.  There is an lbl_checkedCalc() method available for this purpose.
> 
> The most major change is in how the absorption lines are stored.  The old 
> abs_lines and abs_lines_per_species still exists.  They are now arrays of 
> AbsorptionLines rather than arrays of LineRecord.  The reading routines for 
> this has changed.  There are several Read* functions that output the 
> abs_lines variable.  They should be used to read the data.
> 
> Lastly, the NLTE variables has had to become a class of their own instead of 
> compromised of several matching variables.  

[arts-dev] ARTS Microwave Single Scattering Properties Database (Oriented Particles) Version 1.0 released

[Oliver Lemke]

Hi all,

We are pleased to announce that the ARTS Microwave Single Scattering Properties 
Database (Oriented Particles) has been released and is available for download 
on Zenodo[1].

The database contains microwave and submillimeter wave single scattering data 
of azimuthally randomly oriented frozen hydrometeors. It contains one aggregate 
habit and one pristine ice crystal habit. Furthermore, 35 frequencies from 1 to 
886 GHz, and 3 temperatures, 190, 230 and 270 K, are included. 

The Python3 interface of ARTS Microwave Single Scattering Properties Database 
Interfaces[2] can be used for browsing and importing of the single scattering 
data of azimuthally randomly oriented.

Information and download links can also be found in the tools section of the 
ARTS webpage[3].

Best wishes,
The ARTS Developers


[1] https://doi.org/10.5281/zenodo.3463003
[2] https://doi.org/10.5281/zenodo.1175588
[3] http://www.radiativetransfer.org/tools/#ssd



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] ACTION REQUIRED: New code style applied to ARTS source

[Oliver Lemke]

Hi all,

The whole ARTS code has been reformatted to follow the Google Code style.

Before doing any changes update your working copy!!! Otherwise you will get 
merge
conflicts later.

Cheers,
Oliver

___
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] Renaming of constants

[Oliver Lemke]

Hi Simon,

How should I proceed with the reformatting with clang-format? Should I go 
ahead, or should we postpone it as well? I don't want to create a whole bunch 
for merge issues for you.

Cheers,
Oliver


> On 2 Sep 2019, at 07:08, Simon Pfreundschuh  
> wrote:
> 
> Hi Richard,
> 
> Thanks for your feedback. I agree that we should try to get rid of 
> constants.cc and
> unify the handling of constants in ARTS. I started some refactoring but ran 
> into the
> problem of some of the tests related to lineshapes becoming instable. I am 
> still in
> the process of tracking this down, but it will have to wait until later this 
> week or
> after the ARTS week.
> 
> Regards,
> 
> Simon
> From: Richard Larsson 
> Sent: Tuesday, August 27, 2019 10:48:49 AM
> To: Simon Pfreundschuh
> Cc: ARTS Development List
> Subject: Re: [arts-dev] Renaming of constants
>  
> Hi Simon,
> 
> I think that this is a good idea. I would go further and remove all of 
> constants.cc while you are at it.  Or as much as possible.
> 
> Some notes:
> 
> You have misunderstood one thing.  The Delta_nu_Cs variable is a properly 
> named snake_case variable that follows the naming convention of the 
> International System of Units.  The Greek letter Delta is used by them, the 
> Greek letter nu is used them, and cesium in short is Cs, not cs.  Of the 
> variables in Constant, two are clearly not following the proper naming 
> (though I might have missed others).  NA should be N_A and k should be k_B to 
> be consistent with SI standard notation in snake_case.  If you wish to change 
> to another case style, whatever else your do, please be consistent with 
> capitalization in SI, so that (for example) DeltanuCs is both the Pascal and 
> camel case of said variable.  Please do not make up your own variable names 
> while ignoring SI standards as this will just reduce the readability of the 
> code.  Your example of kDeltaNuCs is one example of making up a new variable 
> name, since Nu is not used in the SI standard notation (and so it should not 
> be in ARTS).
> 
> The extra "k" at top is very very ugly and I think that it should not be 
> there.  Just use the namespace instead to separate these things.  This is in 
> the Google style anyways.  Exceptions to this would be in the Conversion 
> namespace, where a k at the top might be warranted (since the variables are 
> not really meant to be used but instead the conversion formula should be 
> used).
> 
> I am unsure what Google believes about the use of static in the namespace 
> code.  This should perhaps be removed.
> 
> The Conversion namespace is completely messed up in naming and can be changed 
> as you please.  If you are renaming these variables anyways, using 
> Conversion::sind and the rest of the degree-based trigonometry whenever 
> possible (i.e., in most of m_ppath and ppath) would be good since it makes 
> the code easier to read (by making it shorter).
> 
> With hope,
> //Richard
> 
> On Tue, Aug 27, 2019, 08:03 Simon Pfreundschuh 
>  wrote:
> Dear all,
> 
> We are currently in the process of establishing more explicit coding 
> guidelines
> with the aim of improving consistency and ultimately the quality of the ARTS
> code base. To make our life easier, it has been decided that we try to adhere
> to the google C++ coding style, at least w.r.t. naming and formatting 
> conventions.
> 
> One problem that I encountered is that the naming of constants, at least those
> defined in constants.[h, cc], is not consistent. Currently some of the names 
> are
> all caps (AVOGADROS_NUMB, why are you screaming at me?), others use mixed
> case (Delta_nu_Cs) and others only use small letters.
> 
> In lack of a better idea, I would propose to change this to follow the google 
> style
> guide. This would mean prefixing all constant names with a k followed by the
> variable name in camel case:
> 
> kAvogadrosNumb, kDeltaNuCs, ...
> 
> One could certainly argue that, since the constants are already in the 
> Constants
> name space, they can be easily identified as constants. Anyhow, I think 
> there's an
> advantage of indicating the constant nature of these variables in their name 
> and
> to do this consistently with other constants defined in the code.
> 
> If none of the other developers opposes this, I would go on to rename the 
> constants
> defined in constants.[h, cc] and others I find in the code to homogenize this.
> 
> Looking forward to your input!
> 
> Regards,
> 
> Simon
> ___
> 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

[arts-dev] PSA: Do not use CLion 2019.2.x for ARTS development

[Oliver Lemke]

Hi all,

There is currently a weird bug in the code analysis of CLion in combination 
with Eigen. Please use 2019.1.4 for ARTS development to avoid this issue. You 
can downgrade or install the older version in parallel via the JetBrains 
Toolbox.

https://youtrack.jetbrains.com/issue/CPP-17274

Cheers,
Oliver

___
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] ARTS is now on GitHub, what's changed?

[Oliver Lemke]

Hi all,

The move to GitHub is now complete. Yay! 

https://github.com/atmtools/arts/

In this mail I'll summarise the most important changes in the development 
workflow.

1 - Better tracking of changes

With Subversion, being a centralised version control system, every commit had 
to be done right on the server. In the past, this often led to the point where 
larger changes resulted in huge commits that touched many files. A finer 
granularity in commits makes it easier for other developers to follow what's 
going on. It can also help to better track down problems to a specific change 
causing them.

Git is decentralised. You develop in your own fork ("copy") of the repository. 
You can commit your changes more often and thus keep better track of your 
changes before they end up in the "live" version. After merging these 
finer-grained commits will be retained in the main repository, making it easier 
for other developers to follow your changes. If you're working on different 
things simultaneously, branches enable you to keep these things physically 
separate, giving you the opportunity to commit them when they're ready.

Information on how to work with git can be found in this document:

https://github.com/atmtools/arts/blob/master/CONTRIBUTING.md


2 - Code Review

Another common practice we'd like to adapt is code review. Having another pair 
of eyes look at the code increases the chance of spotting potential problems as 
early as possible. In GitHub this is done via pull requests. Once you're done 
with your current work, instead of merging your changes directly into the main 
repository, you open a pull request. A maintainer (currently Simon and I), will 
have a look at your changes, request changes if any problems are spotted and 
then merge your branch into the main repository.


3 - No more ChangeLog _file_

The ChangeLog file has been removed for several reasons:

- It is duplicating the information available via the log history of the 
version control system (either 'svn log' or 'git log'). 
- It can lie or not tell the whole truth. If you want to see which files 
changed in a particular commit, looking at the ChangeLog file might only give 
you part of that information. The committer could have forgotten to list _all_ 
the changed files. The version control system know exactly which files have 
changed 'git log --stat'.
- It creates a singular point of merge conflicts when working with branches.


4 - But... what about the ARTS version number?

- It now lives in its own file 'VERSION' in the top level ARTS directory.
- The way we used it also duplicated functionality already provided by the 
version control system (the commit hash in git, or the revision id in 
Subversion).
- The version will only be incremented by the maintainers in the master 
repository. Either when new major new features have been added, the user 
interfaces changed (e.g. changed WSM interfaces). But never in developer 
branches.


5 - Code format, not git related but I'll mention it here anyway

Over the years, coding style has "evolved" into very different styles for 
different files in ARTS. After looking at different widely used styles, Simon 
and I decided to go with the Google Coding Style. With clang-format being 
available as a great tool for automatically applying a style to the code (not 
only indentation, but also consistent in-code whitespace), this is a great 
opportunity to bring back consistent formatting to ARTS. I'll send out a 
separate mail with more information on plans how to apply the new format to all 
ARTS code.


I think that's all for now. As with every switch to a new system, I expect 
there to be some rough edges that we have to work out.

Questions or comments are always welcome.

Best wishes and have a great weekend,
Oliver

___
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] ARTS GitHub migration status update

[Oliver Lemke]

Hi all,

It took a bit longer than expected, but we're almost there.

Here is the current status of the GitHub migration:

- ARTS repository is now available on GitHub:
  https://github.com/atmtools/arts
- ARTS SVN repository has been renamed
- ARTS website (Getting ARTS, Tools) has been updated

I'll send a more detailed mail on what's changed in the workflow for developing 
ARTS tomorrow. If you like, you can already have a look at the documentation in

https://github.com/atmtools/arts/blob/master/CONTRIBUTING.md

Cheers,
Oliver

___
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

[Oliver Lemke]

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

[arts-dev] Pre-Announcement: ARTS moving to GitHub

[Oliver Lemke]

Hi all,

By the end of next week, the ARTS source code will move from our subversion 
repository to GitHub.

If you have local changes, please commit them to the subversion repository 
before Wednesday, August 21 23:59.

Detailed information on changes in the workflow for developers will be provided 
during the next week.

Cheers,
Oliver

___
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] MT-CKD 3.2.0 H2O continua

[Oliver Lemke]

Hi Stuart,

> On 13 Nov 2018, at 14:30, Fox, Stuart  wrote:
> 
> I have a new version of ARTS that includes v3.2.0 of the MT-CKD H2O continua, 
> implemented by Emma Turner that I’d like to check in to the subversion 
> repository. How do I get a username and password to do this?

I'll send you a link to the registration page in a separate mail. After you've 
submitted the form, I'll let you know when the account is ready.

If you have any questions about the commit procedure, just let me know. We 
really appreciate that you decided to contribute that code to ARTS.

> Also, the changes have broken the (slow) test 
> arts.ctlfile.xmldata.artscomponents.clearsky.TestClearSkyTips as there is no 
> corresponding entry in arts-xml-data/spectroscopy/PartitionSums/TIPS/tips.xml 
>  file. Should this file be edited by hand (and submitted as a new version of 
> arts-xml-data), or is it autogenerated somehow? I’m guessing that 
> arts-xml-data/spectroscopy/PartitionSums/VIBROT/vibrot.xml also needs to be 
> changed, although there are no tests for that.

Since the values for all the continua are the same, it is probably easiest to 
just add an entry by hand. You don't need to do that. I can take care of it 
after you've committed the code to arts.

Cheers,
Oliver

___
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] Generating arts_theory.stage1 fails with: No such file or directory

[Oliver Lemke]

Ah, ok. Yes, that explains it. ~ is only meant for interactive use, everywhere 
else $HOME is the way to go. Thanks again for your feedback to get to the 
bottom of this issue. I'll remove the extra PATH assignment anyway in an 
upcoming commit because as you pointed out, it's not needed there.

Cheers,
Oliver


> On 6 Mar 2018, at 14:40, Jonas Hagen <jonas.ha...@iap.unibe.ch> wrote:
> 
> Ah, my PATH contained a ~ character which made cmake to quote the whole 
> string. Obviously this is a bad thing to have and should be avoided. Funny 
> that this never was a problem except with arts theory build.
> 
> Thanks for asking the questions!
> 
> BTW: I use cmake 3.5.1 (from March 2016) which is the current version in the 
> Ubuntu 16.04 LTS repos.
> 
> Cheers,
> Jonas
> 
> 
> On 06.03.2018 11:26, Oliver Lemke wrote:
>> True, that the quotes screw it up. But the question is why they appear for 
>> you, but not for others. This is the first time I hear about this problem. 
>> That's what confuses me and I'm trying to wrap my head around what triggers 
>> this issue. :-)
>> 
>> Which cmake version do you use?
>> 
>> Cheers,
>> Oliver
>> 
>> 
>>> On 6 Mar 2018, at 11:17, Jonas Hagen <jonas.ha...@iap.unibe.ch> wrote:
>>> 
>>> Hi Oliver
>>> 
>>> I'm using Ubuntu 16.04 LTS and the bash shell. The problem is that the 
>>> PATH= assignment in front of the makeindex command is in quotes. In bash 
>>> this does not work:
>>> 
>>> user@host:/$ "VAR=value" ls
>>> VAR=value: command not found
>>> 
>>> whereas this does work:
>>> 
>>> user@host:/$ VAR=value ls
>>> ...
>>> 
>>> I could not figure out how to make proper quoting. But the PATH assignment 
>>> is not needed in front of makeindex, as it is called with an absolute path.
>>> 
>>> Cheers,
>>> Jonas
>>> 
>>> 
>>> On 06.03.2018 07:06, Oliver Lemke wrote:
>>>> Hi Jonas,
>>>> 
>>>> Thanks for the feedback. I'm curious why this happens in your case. On 
>>>> which operating system are you? Is your makeindex command located in 
>>>> /usr/bin ('which makeindex')?
>>>> 
>>>> Cheers,
>>>> Oliver
>>>> 
>>>> 
>>>>> On 5 Mar 2018, at 12:04, Jonas Hagen <jonas.ha...@iap.unibe.ch> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> When building ARTS, the task "Generating arts_theory.stage1" fails with:
>>>>> 
>>>>> /bin/sh: PATH:/usr/bin:: No such file or directory
>>>>> 
>>>>> See verbose output in the attachment. For me, just removing the path in 
>>>>> front of the makeindex command resolves the problem (see attached patch). 
>>>>> Maybe there are better solutions. I think this has been around for quite 
>>>>> a while, until now we just ignored the error, as the important parts are 
>>>>> being built before this error happens. Maybe this is useful to somebody.
>>>>> 
>>>>> Best regards,
>>>>> Jonas Hagen
>>>>> 
>>>>> 
>>>>> ___
>>>>> 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] Typhon is moving to github

[Oliver Lemke]

Hi all,

Typhon has now been moved to its new home at github.

You can checkout the latest version with:

git clone https://github.com/atmtools/typhon

For information of contributing to typhon please see the current version of 
this document:

https://github.com/atmtools/typhon/blob/master/CONTRIBUTING.md

Cheers,
Oliver


> On 13 Sep 2017, at 14:41, Oliver Lemke <oliver.le...@uni-hamburg.de> wrote:
> 
> Dear friends and developers of typhon,
> 
> To extend the reach and exposure of the typhon project, as well as profiting 
> from the features of the git version control system, we have come to the 
> conclusion that it is in the best interest of the project to move the typhon 
> repository to github.com .
> 
> The move will take place next Monday, September 18. Write access to the SVN 
> repository will be locked at 7am CEST[1].
> 
> To make the move as smoothly as possible, we recommend that you commit any 
> pending changes before this time. Otherwise you'll have to add your changes 
> to the github version after the move.
> 
> Lukas prepared a nice overview how contributing to typhon will work in the 
> future. You can find the preliminary instructions here:
> 
> https://github.com/olemke/typhon/blob/master/CONTRIBUTING.md
> 
> These instructions might be revised in the future as this is also the first 
> time for us as maintainers to host a public project on github. Best practices 
> and workflows will need some time to manifest. We're looking forward to this 
> exciting journey together with you. :-)
> 
> The new home of the typhon repository will be found under our 'atmtools' 
> group:
> 
> https://github.com/atmtools/
> 
> If you have any comments or questions, please don't hesitate contact us.
> 
> Best wishes,
> Oliver and Lukas
> 
> [1] 
> https://www.wolframalpha.com/input/?i=7:00+am+CEST++%7C++September+18,+2017
> 

___
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

[Oliver Lemke]

Hi Simon,

That's great news. This is a very good foundation for further integration 
between Python and ARTS.

Cheers,
Oliver


> 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

___
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] BLAS/LAPACK detection

[Oliver Lemke]

Hi all,

I've just committed a change in arts-2-3-730 to simplify the BLAS/LAPACK 
detection. If you get cmake errors concerning LAPACK in this version, please 
let me know.

cheers,
/oliver


___
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] Making C++11 the default for ARTS

[Oliver Lemke]

Hi all,

Since the latest C++17 standard is currently added into the compilers, I think 
it is time that we start to utilise the features of C++11 in ARTS. It has been 
in the compilers for a while and is well supported nowadays.

As a first step, I have set C++11 compiler support as a requirement in 
arts-2-3-710. Also, the requirement for the installed cmake version has been 
increased from 2.8 to 3.1 .

Please update to the latest ARTS version and let me know of any issues you 
encounter.

If you're still using Ubuntu LTS 14.04, you need to update cmake to the newer 
version. This can be easily done by adding a PPA and upgrade from there:

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:george-edison55/cmake-3.x
sudo apt-get update

sudo apt-get install cmake

cheers,
/oliver

___
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

[Oliver Lemke]

Hi Stuart,

I've added (hopefully) all the missing continua to the standard include file in 
arts-2-3-621.

Thanks for reporting this issue.

Cheers,
Oliver


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

___
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

[Oliver Lemke]

Hi Ian,

I've committed your patch in arts-2-3-588. Thanks a lot for your contribution.

If you have any additions/fixes in the future, we'd be happy to give you commit 
permissions for the repository.  Just let me know and I'll setup an account for 
you.

Cheers,
Oliver


> On 22 Dec 2016, at 19:06, Ian S. Adams <ian.ad...@nrl.navy.mil> wrote:
> 
> Oliver,
> 
> The ARTS SVN revision number is 10107. I did not include the patch file since 
> I have introduced newer code into ARTS that I am not ready to commit yet.
> 
> Thanks,
> Ian
> 
> 
> 
> On Dec 22, 2016, at 7:37 AM, Oliver Lemke <oliver.le...@uni-hamburg.de> wrote:
> 
> Hi Ian,
> 
> Great to see that adding the Radar Monte Carlo code worked out so well. I'd 
> be happy to commit your code to the ARTS repository. But I won't manage 
> before January as I'm on vacation from tomorrow until January 5.
> 
> To make it easier for me to commit the changes, could you please provide them 
> as a patch file? You can create it by running 'svn diff > radar.patch' in the 
> top-level arts directory. Alternatively, let me know on which exact ARTS SVN 
> revision number the files you provided are based upon (run 'svn info | grep 
> Revision' in the arts directory).
> 
> This way I can apply the changes cleanly and don't accidentally revert 
> anything that has changed in the meantime.
> 
> Thanks for helping to push ARTS forward!
> 
> Happy Holidays,
> Oliver
> 
> 
>> On 21 Dec 2016, at 21:27, Ian S. Adams <ian.ad...@nrl.navy.mil> 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
>> 
>> 
> 
> 
> 
> ___
> 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

[Oliver Lemke]

Hi Ian,

Great to see that adding the Radar Monte Carlo code worked out so well. I'd be 
happy to commit your code to the ARTS repository. But I won't manage before 
January as I'm on vacation from tomorrow until January 5.

To make it easier for me to commit the changes, could you please provide them 
as a patch file? You can create it by running 'svn diff > radar.patch' in the 
top-level arts directory. Alternatively, let me know on which exact ARTS SVN 
revision number the files you provided are based upon (run 'svn info | grep 
Revision' in the arts directory).

This way I can apply the changes cleanly and don't accidentally revert anything 
that has changed in the meantime.

Thanks for helping to push ARTS forward!

Happy Holidays,
Oliver


> On 21 Dec 2016, at 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
> 
> 

___
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] bug or feature: metmm freq_number vs. freq_spacing

[Oliver Lemke]

> On 4 Mar 2016, at 08:43, Jana Mendrok  wrote:
> 
> 
> For ISMAR the number of frequencies for the fastest accuracy is not set to 1 
> for all channels ike for other sensors. Instead channels 10-13,19,20 are set 
> to -1 which means the default frequency spacing is used instead.
> 
> no, now we do definitely missunderstand each other. the ones you point out 
> are channels not yet implemented. look at the other settings for them. plenty 
> of question marks there. ;-)
> what i mean is e.g. happening for channel 18, which is a very broad channel. 
> there the 1GHz spacing overrules the freq_number = 1 set for metmm_accuracy=0 
> and results in 5 freq points per passband.

Ah, ok, sorry for the confusion. Got it now. Yes, that can happen. I don't 
think that was intentional. We'll have to find a way to set the frequency 
spacing wide enough for those cases to avoid that from happening. I'll discuss 
it with Alex.

cheers,
/oliver

___
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] bug or feature: metmm freq_number vs. freq_spacing

[Oliver Lemke]

Hi Jana,

Now I get what you mean. :-)

For ISMAR the number of frequencies for the fastest accuracy is not set to 1 
for all channels like for other sensors. Instead channels 10-13,19,20 are set 
to -1 which means the default frequency spacing is used instead.

I'll discuss that with Alex. Maybe those channels where just too inaccurate 
with 1 frequency? Anyway, just guessing here. We'll get back to you after 
discussion. Thanks for pointing this out.

cheers,
/oliver


> On 3 Mar 2016, at 19:31, Jana Mendrok <jana.mend...@gmail.com> wrote:
> 
> Hi Stefan,
> 
> I do understand that the WSM f_gridMetMM provides the tighter of the two.
> 
> but aren't the sensor descriptions with freq_number set depending on 
> metmm_accuracy levels tailor-made with respect to speed and a threshold 
> accuracy? why would we prepare them first to then overwrite them (e.g. 
> slowing down the "very very fast" setup significantly at least for ICI/ISMAR, 
> and occasionally forcing the f_grid to contain more points than necessary for 
> the intended and documented accuracy threshold)? does not really make sense 
> to me.
> 
> i assumed metmm_accuracy=0 should ALWAYS setup a f_grid with exactly one grid 
> point per passband. the user can still overwrite this of course by 
> (re-)setting either of freq_number and freq_spacing. but here, we provide a 
> setting that overwrites itself. as written, seems odd to me. 
> 
> couldn't find this behaviour in documentation neither. the amsu-metmm report 
> says "The first configuration selects 1 frequency in the middle of every 
> channel. The second, third and fourth configuration select different numbers 
> of frequencies for every channel." and doesn't ever mention spacing.
> 
> but if you're sure that's what you want, i stop complaining ;-)
> wishes,
> Jana
> 
> On Thu, Mar 3, 2016 at 6:15 PM, Stefan Buehler 
> <stefan.bueh...@uni-hamburg.de> wrote:
> Hi Jana,
> 
> this behaviour is intentional, you are guaranteed to get a least the 
> frequency number and spacing you specified. The tighter constraint wins.
> 
> Best wishes,
> 
> Stefan
> 
> > On 02 Mar 2016, at 14:06, Oliver Lemke <oliver.le...@uni-hamburg.de> wrote:
> >
> > Hi Jana,
> >
> > In general, the higher accuracy always wins. So, if the bandwidth divided 
> > by freq_numbers is larger than freq_spacing, the latter will be used.
> >
> > Whether the behaviour you see with metmm_accuracy is intentional, I leave 
> > to Alex to comment on.
> >
> > cheers,
> > /oliver
> >
> >
> >> On 2 Mar 2016, at 10:46, Jana Mendrok <jana.mend...@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> when running the metmm system with the provided sensor setups, i had 
> >> expected that the set freq_numbers (depending on metmm_accuracy choice) 
> >> are ruling, ie. it's always them that are applied.
> >> however, i found that freq_spacing is set such that it overrules 
> >> freq_number occasionally (eg. several of the ISMAR channels with 
> >> metmm_accuracy=0, leading to 58 f_grid points for the 15 existing ISMAR 
> >> channels, instead of 2x15=30 I had expected).
> >>
> >> is this intended behaviour? or a bug?
> >>
> >> wishes,
> >> Jana
> >
> > ___
> > 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
> 
> 
> 
> -- 
> =
> Jana Mendrok, Ph.D. (Project Assistent)
> Chalmers University of Technology
> Earth and Space Sciences
> SE-412 96 Gothenburg, Sweden
> 
> 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

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