[arts-users] Issues using "scat_data" in ARTS dev version

[Thomas,Renish]

Dear ARTS Community,

I am using the dev version of ARTS to use some of the newer workspace methods 
and was experiencing issues with "scat_data".
After loading 'scat_data,' the values say: "SingleScatteringData: Output 
operator not implemented."
As this was not an issue with the stable ARTS 2.4 version, I'd like to know if 
something has changed with the scattering data functions.

Any help or hints are appreciated!

Sample error Info:
ws.scat_data.value
Out[19]: [[SingleScatteringData: Output operator not implemented, 
SingleScatteringData: Output operator not implemented, SingleScatteringData: 
Output operator not implemented, SingleScatteringData: Output operator not 
implemented
Thanks very much!

Version: arts-2.5.7 (compiled 2022-11-22 13:20:32)

Renish Thomas
Microwave Systems Laboratory
Colorado State University
Fort Collins, CO

[arts-users] Issues using the "opt_prop_sptFromData" Method

[Thomas,Renish]

Dear ARTS Community,

I am experiencing some issues with extracting optical properties of scattering 
particles such as 
"ext_mat_spt"
 and 
"abs_vec_spt"
 using the 
"opt_prop_sptFromData"
 workspace method.

The Runtime Issue:

=> The python kernel crashes {"Aborted (core dumped)"} during runtime when the 
"opt_prop_sptFromData"
 method is executed.

=> I am encountering two types of runtime errors based on za_grid and za_index.

=> During traceback, the runtime errors seem to be caused by checks on 
"za_index" and "aa_index".

=> When za_grid or aa_grid is empty===runtime error=>
python: /arts/src/matpackI.h:509: Numeric ConstVectorView::operator[](Index) 
const: Assertion `n < mrange.mextent' failed.

=> When za_grid or aa_grid is not empty===runtime error=>
python: /arts/src/array.h:215: base& Array::operator[](Index) [with base 
= PropagationMatrix; Index = long int]: Assertion `n < nelem()' failed.

The Scattering Data:

=> The scattering data is extracted from the "totally_random" scattering 
particles "LiquidSphere_TotRand" from the ARTS single-scattering properties 
database.

=> ws.scat_data.za_grid = array([0.0,0.2,.,90,,179.8,180]).  Zenith 
angle grid from scat_data.

=> ws.scat_data.aa_grid = array([ ])  Empty azimuth angle grid from scat_data.

My Questions:

=> What could be the reason for the runtime errors?

=> Should I assign the same "za_grid" from "scat_data" when using the 
"opt_prop_sptFromData"
 method? or is the "za_grid" selection dependent on something else?

=> Should I leave the aa_grid empty as mentioned in the ARTS user guide for 
totally random particles when using 
"opt_prop_sptFromData"?.
 How would I do this without errors?

=> How do I select za_index intuitively? Should I loop through all elements or 
do all the index values give game results for "totally_random" scattering 
particles. An example or illustration would help. The lab and scattering 
coordinate transformation is making the selection of za_grid and za_index vague 
to me.

Misc Info:

=> ARTS Version: arts-2.5.0
=>  Pyarts

Thanks very much!
Renish Thomas


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

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

[Thomas,Renish]

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.mi@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.mi@lists.uni-hamburg.de<mailto:arts_users.mi@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.mi@lists.uni-hamburg.de<mailto:arts_users.mi@lists.uni-hamburg.de>
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=04%7C01%7CRenish.Thomas%40colostate.edu%7C8bb1cd94b52a4724954408d903ed19cb%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545139171957024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7Qr43Du%2B54FAx%2FWFOIMnjdaHFegsWnBRslp2jGQYxb8%3D&reserved=0<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=04%7C01%7CRenish.Thomas%40colostate.edu%7C3cb4ae984f594bc5fc1408d903f16e00%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545157742334188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rAhkk83NkUW%2B6P7%2FQRS8%2FHW4h2Q12rLfUHYPz11kY0U%3D&reserved=0>
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de<mailto:arts_users.mi@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&data=04%7C01%7CRenish.Thomas%40colostate.edu%7C3cb4ae984f594bc5fc1408d903f16e00%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545157742339161%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=p80qF1gIuNiInE4syM5IUH%2B8JQSbdFojjKj3X1XE2b4%3D&reserved=0>
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

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

[Thomas,Renish]

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 
Date: 4/20/21 6:11 AM (GMT-06:00)
To: "Thomas,Renish" 
Cc: "arts_users.mi@lists.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.mi@lists.uni-hamburg.de
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=04%7C01%7CRenish.Thomas%40colostate.edu%7C8bb1cd94b52a4724954408d903ed19cb%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637545139171957024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7Qr43Du%2B54FAx%2FWFOIMnjdaHFegsWnBRslp2jGQYxb8%3D&reserved=0
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

[arts-users] Calculated brightness temperature bias causes.

[Thomas,Renish]

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

Re: [arts-users] ARTS Scattering Jacobians

[Thomas,Renish]

Hi Patrick,

Thanks for the information on the scattering jacobians.

Are the clear sky jacobians fully functional in ARTSv2.5?

Meaning, are they only to be used with nadir and zenith viewing geometries? or 
can they be used even for horizon viewing geometries when the sensor is inside 
the atmosphere?

Thanks,
Renish Thomas

From: Patrick Eriksson 
Sent: Thursday, February 4, 2021 2:32 AM
To: Thomas,Renish ; 
arts_users.mi@lists.uni-hamburg.de 
Subject: Re: [arts-users] ARTS Scattering Jacobians

Thomas,

Jacobian calculations in ARTS we still see as work in progress and there
are strong restrictions. So we keep this so far a bit on the side.

In short, the only method that can produce Jacobians with scattering is
iyHybrid (that totally lacks documentation). This one only works in 1D
(as it using DISORT or RT4 in the background). In addition, the Jacobian
is approximative. It works both inside and outside of cloudbox.

Further, there have been some changes to the code and the exact status
of the method in v2.5 is a bit unclear. We will likely use it soon and
will then make some checks.

Sorry, but this is the status ...

Bye,

Patrick


On 2021-02-04 06:43, Thomas,Renish wrote:
>
> Hi Everyone,
>
> I had a couple of questions about jacobian calculations in ARTS.
>
> The ARTS user guide in chapter 16 mentions that none of the scattering
> methods can provide jacobians, and currently only works in clear sky cases.
>
> But, the ARTS built-in documentation shows the methods
> "jacobianAddScatSpecies" and "jacobianAddSpecialSpecies" .
>
> So, my questions are:
>
> 1.)  Can the Monte Carlo module be used along with
> "jacobianAddScatSpecies" to calculate jacobians in a cloud box area
> containing multiple scattering species?
>
> 2.)  Can the above said method be used to calculate jacobians throughout
> the atmosphere in a scenario where some part of the atmosphere is
> cloudbox and rest is clearsky.
>
> 3.) Is there an ARTS method for 3D atmosphere to calculate the jacobians
> only along the line of sight of the sensor and not the complete
> atmosphere?, without defining the retrieval grid?
>
> Cheers,
> Renish
>
>
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=04%7C01%7CRenish.Thomas%40colostate.edu%7Cbd3d4cee3f024954624208d8c8efc1ec%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637480279380992673%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=KEicU4%2BIwsnpR24xpuIUMVYGstDq%2B9q7HfFnJQHN%2FAo%3D&reserved=0
>
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

[arts-users] ARTS Scattering Jacobians

[Thomas,Renish]

Hi Everyone,

I had a couple of questions about jacobian calculations in ARTS.

The ARTS user guide in chapter 16 mentions that none of the scattering methods 
can provide jacobians, and currently only works in clear sky cases.

But, the ARTS built-in documentation shows the methods "jacobianAddScatSpecies" 
and "jacobianAddSpecialSpecies" .

So, my questions are:

1.)  Can the Monte Carlo module be used along with "jacobianAddScatSpecies" to 
calculate jacobians in a cloud box area containing multiple scattering species?

2.)  Can the above said method be used to calculate jacobians throughout the 
atmosphere in a scenario where some part of the atmosphere is cloudbox and rest 
is clearsky.

3.) Is there an ARTS method for 3D atmosphere to calculate the jacobians only 
along the line of sight of the sensor and not the complete atmosphere?, without 
defining the retrieval grid?

Cheers,
Renish

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

Re: [arts-users] Fwd: Re: ARTS internally generated PND fields

[Thomas,Renish]

Hi Patrick,

Thanks for the suggestions.

1.)
=> I tried to check if Dmean was set to 0 value anywhere in the Bulkprop_fields 
when using "psdModifiedGammaMassXmean()" . The only place it is '0' is at the 
border of the cloudbox and outside the cloudbox.
=> This is how "pnd_fieldCalcFromParticleBulkProps()" expects to be set as 
given in the documentation.
=> When I try making the border values a positive non-zero value. It gives me 
this error.
Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
error: *particle_bulkprop_field* allowed to contain non-zero values only inside 
the cloudbox.


2.)
=> So, this looks to me like a bug that if I make borders zero valued then 
"psdModifiedGammaMassXmean()" would have a problem, else if I make it non zero 
then
"pnd_fieldCalcFromParticleBulkProps()"  will give me problems.
=> Am I thinking this right?


3.)
=> Would you recommend me to change the source code in "PSD.CC" and change line 
321 "if (ext_pars[1] <= 0) " and remove the "=" sign and build ARTS.
Would this be a fix to the problem?


Thanks,
Renish Thomas

________
From: Patrick Eriksson 
Sent: Sunday, December 6, 2020 10:59 AM
To: Thomas,Renish 
Cc: arts users mi 
Subject: Re: Fwd: Re: [arts-users] ARTS internally generated PND fields

Ranish,

> 1.) So, if I must set the scattering particle temperature to an arbitrary 
> value after
> calling "pnd_fieldCalcFromParticleBulkProps", do I just override and assign
> 'pnd_agenda_input_t".

You got me wrong. You don't need to do anything. pnd_agenda_input_t is set 
automatically
where needed.


> 2.) Can the particle temperature be set different than the ambient 
> temperature?

Hardly. You can in principle try to "hack" pnd_agenda to set it to some other 
value. But
why do you want to do it?

And please note that the psdModifiedGamma PSD-s do not even have a temperature 
dependence.
So in this case I really don't see any reason.

The temperature also comes into play when interpolating scat_data, but that is 
handled by
another part of ARTS. And over there, there is no option beside using the local 
temperature.


> 3.) Do you recommend me to use internally generated PSD for MC or set it 
> externally?

What you have started should work. So continue on this track.

(The alternative is to set pnd_field already in Python. Then you can ignore
particle_bulkprop_field ad pnd_agenda etc.

I can also mention that the PSD system in ARTS v2.5 soon will change. Simon is 
making a
complete revision of the handling of particles.)

Bye,

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

Re: [arts-users] Fwd: Re: ARTS internally generated PND fields

[Thomas,Renish]

Hi Patrick,

Thanks for the suggestions.

1.)
=> I tried to check if Dmean was set to 0 value anywhere in the Bulkprop_fields 
when using "psdModifiedGammaMassXmean()" . The only place it is '0' is at the 
border of the cloudbox and outside the cloudbox.
=> This is how "pnd_fieldCalcFromParticleBulkProps()" expects to be set as 
given in the documentation.
=> When I try making the border values a positive non-zero value. It gives me 
this error.
Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
error: *particle_bulkprop_field* allowed to contain non-zero values only inside 
the cloudbox.


2.)
=> So, this looks to me like a bug that if I make borders zero valued then 
"psdModifiedGammaMassXmean()" would have a problem, else if I make it non zero 
then
"pnd_fieldCalcFromParticleBulkProps()"  will give me problems.
=> Am I thinking this right?


3.)
=> Would you recommend me to change the source code in "PSD.CC" and change line 
321 "if (ext_pars[1] <= 0) " and remove the "=" sign and build ARTS.
Would this be a fix to the problem?


Thanks,
Renish Thomas

____
From: Patrick Eriksson 
Sent: Sunday, December 6, 2020 8:25 AM
To: Thomas,Renish 
Cc: arts users mi 
Subject: Re: Fwd: Re: [arts-users] ARTS internally generated PND fields

Renish,

Let me first clarify that temperature is not meant to be part of 
particle_bulkprop_field.
pnd_fieldCalcFromParticleBulkProps interpolates t_field to set 
pnd_agenda_input_t. As this
is done inside a method, the workspace version of pnd_agenda_input_t is left 
unset.

Note that the unit of hydrometeor mass contents is kg/m3. It seems that you set
"Mass_Content" to 1 kg/m3. A more realistic value would be 1 g/m3, or lower.

Regarding the use of psdModifiedGammaMassXmean, I don't spot any obvious error. 
It could
be a bug. This PSD has not been used a lot, or maybe not all. And you are 
likely the first
to combine MC and this PSD system.

I checked the code and even Xmean == 0 will cause the error. Could it be that 
the PSD is
called for a point where your Dmean is zero?

To check, can you try to run MC with one core, and add

Print(pnd_agenda_input,0)

just before calling psdModifiedGammaMassXmean (inside of the agenda).

Bye,

Patrick



On 2020-12-05 19:38, Thomas,Renish wrote:
> Hi Patrick / ARTS users,
>
> 1) I am trying to run full calculations using the MC_General() method, after 
> setting the
> PSD fields internally.
>
> 2) =>The full calculations do run without errors when I use 
> [psdModifiedGammaMass].
> => I see the effects of increase in mass content in the simulation, which 
> means the
> bulkprop_fields are read into "ws.pnd_agenda_input".
> =>The only thing is that I don't see is the effect of temperature when after 
> the run. Even
> when I remove the name "Temperature" from "ws.particle_bulkprop_names" it runs
> without  errors. This makes me wonder if the "pnd_agenda_input_t" is set.
> => And, when I try extracting the "ws.pnd_agenda_input_t.value" after the 
> successful run.
> It says that the variable is uninitialized.
>
> 3) When I run with [psdModifiedGammaMassXmean],It gives me the following 
> error.
>
> Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
> error:
> Run-timeerror in agenda: pnd_agenda_array
>
> Run-time error in method: psdModifiedGammaMassXmean
> Negative mean sizefound.
> This is not allowed.
>
>
>
> 4) I have attached the sub-function python control file for setting the 
> scattering fields
> before running MC_General(). Any help would be great.
>
>
> Thanks,
> Renish
>
> --
> *From:* Patrick Eriksson 
> *Sent:* Saturday, December 5, 2020 1:55 AM
> *To:* Thomas,Renish 
> *Cc:* arts users mi 
> *Subject:* Re: Fwd: Re: [arts-users] ARTS internally generated PND fields
> Renish,
>
> Are you doing full calculations, running eg DISORT? If yes, then setting the 
> input to
> pnd_agenda should be automatic.
>
> Or are you trying to use the PSD functions separately?
>
> Can you clarify this before I try to answer? And maybe also send me your 
> control file.
>
> Bye,
>
> Patrick
>
>
>> *Från:* "Thomas,Renish" 
>> *Skickat:* 4 december 2020 16:40:25 CET
>> *Till:* Patrick Eriksson ,
>> "arts_users.mi@lists.uni-hamburg.de" 
>> 
>> *Ämne:* Re: [arts-users] ARTS internally generated PND fields
>>
>> Hi Patrick/ Everyone,
>>
>> Thanks, for the inputs .
>> I was able to clear some of the errors.
>>
>> I have a

Re: [arts-users] Fwd: Re: ARTS internally generated PND fields

[Thomas,Renish]

Hi Patrick/All,

Thanks, and that explains a lot.

1.) So, if I must set the scattering particle temperature to an arbitrary value 
after calling "pnd_fieldCalcFromParticleBulkProps", do I just override and 
assign 'pnd_agenda_input_t".

2.) Can the particle temperature be set different than the ambient temperature?

3.) Do you recommend me to use internally generated PSD for MC or set it 
externally?

Thanks,
Renish Thomas

From: Patrick Eriksson 
Sent: Sunday, December 6, 2020 8:25 AM
To: Thomas,Renish 
Cc: arts users mi 
Subject: Re: Fwd: Re: [arts-users] ARTS internally generated PND fields

Renish,

Let me first clarify that temperature is not meant to be part of 
particle_bulkprop_field.
pnd_fieldCalcFromParticleBulkProps interpolates t_field to set 
pnd_agenda_input_t. As this
is done inside a method, the workspace version of pnd_agenda_input_t is left 
unset.

Note that the unit of hydrometeor mass contents is kg/m3. It seems that you set
"Mass_Content" to 1 kg/m3. A more realistic value would be 1 g/m3, or lower.

Regarding the use of psdModifiedGammaMassXmean, I don't spot any obvious error. 
It could
be a bug. This PSD has not been used a lot, or maybe not all. And you are 
likely the first
to combine MC and this PSD system.

I checked the code and even Xmean == 0 will cause the error. Could it be that 
the PSD is
called for a point where your Dmean is zero?

To check, can you try to run MC with one core, and add

Print(pnd_agenda_input,0)

just before calling psdModifiedGammaMassXmean (inside of the agenda).

Bye,

Patrick



On 2020-12-05 19:38, Thomas,Renish wrote:
> Hi Patrick / ARTS users,
>
> 1) I am trying to run full calculations using the MC_General() method, after 
> setting the
> PSD fields internally.
>
> 2) =>The full calculations do run without errors when I use 
> [psdModifiedGammaMass].
> => I see the effects of increase in mass content in the simulation, which 
> means the
> bulkprop_fields are read into "ws.pnd_agenda_input".
> =>The only thing is that I don't see is the effect of temperature when after 
> the run. Even
> when I remove the name "Temperature" from "ws.particle_bulkprop_names" it runs
> without  errors. This makes me wonder if the "pnd_agenda_input_t" is set.
> => And, when I try extracting the "ws.pnd_agenda_input_t.value" after the 
> successful run.
> It says that the variable is uninitialized.
>
> 3) When I run with [psdModifiedGammaMassXmean],It gives me the following 
> error.
>
> Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
> error:
> Run-timeerror in agenda: pnd_agenda_array
>
> Run-time error in method: psdModifiedGammaMassXmean
> Negative mean sizefound.
> This is not allowed.
>
>
>
> 4) I have attached the sub-function python control file for setting the 
> scattering fields
> before running MC_General(). Any help would be great.
>
>
> Thanks,
> Renish
>
> --
> *From:* Patrick Eriksson 
> *Sent:* Saturday, December 5, 2020 1:55 AM
> *To:* Thomas,Renish 
> *Cc:* arts users mi 
> *Subject:* Re: Fwd: Re: [arts-users] ARTS internally generated PND fields
> Renish,
>
> Are you doing full calculations, running eg DISORT? If yes, then setting the 
> input to
> pnd_agenda should be automatic.
>
> Or are you trying to use the PSD functions separately?
>
> Can you clarify this before I try to answer? And maybe also send me your 
> control file.
>
> Bye,
>
> Patrick
>
>
>> *Från:* "Thomas,Renish" 
>> *Skickat:* 4 december 2020 16:40:25 CET
>> *Till:* Patrick Eriksson ,
>> "arts_users.mi@lists.uni-hamburg.de" 
>> 
>> *Ämne:* Re: [arts-users] ARTS internally generated PND fields
>>
>> Hi Patrick/ Everyone,
>>
>> Thanks, for the inputs .
>> I was able to clear some of the errors.
>>
>> I have a couple more questions. It will be great to have some input on these.
>>
>> 1.)  How do I set "pnd_agenda_input_t"?. Is the name "Temperature" in bulk 
>> prop fields
>> names enough to set this, or should I set this explicitly?
>>
>> 2.) Can the particle temperature be different from the atmosphere 
>> temperature around it?
>>
>> 3.) I have no problems with running psdModifiedGammaMass, while running it. 
>> But while
>> running psdModifiedGammaMassXmean, I get this error.
>>
>> Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
>> error: Run-time
>> error in agenda: pnd_agenda_array
>> Run-time error 

Re: [arts-users] Fwd: Re: ARTS internally generated PND fields

[Thomas,Renish]

Hi Patrick / ARTS users,

1) I am trying to run full calculations using the MC_General() method, after 
setting the PSD fields internally.

2) =>The full calculations do run without errors when I use 
[psdModifiedGammaMass].
=> I see the effects of increase in mass content in the simulation, which 
means the bulkprop_fields are read into "ws.pnd_agenda_input".
=>The only thing is that I don't see is the effect of temperature when 
after the run. Even when I remove the name "Temperature" from 
"ws.particle_bulkprop_names" it runs without  errors. This 
makes me wonder if the "pnd_agenda_input_t" is set.
=> And, when I try extracting the "ws.pnd_agenda_input_t.value" after the 
successful run. It says that the variable is uninitialized.

3) When I run with [psdModifiedGammaMassXmean],It gives me the following error.

Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
error: Run-time error in agenda: pnd_agenda_array

Run-time error in method: psdModifiedGammaMassXmean
Negative mean sizefound.
This is not allowed.


4) I have attached the sub-function python control file for setting the 
scattering fields before running MC_General(). Any help would be great.


Thanks,
Renish




From: Patrick Eriksson 
Sent: Saturday, December 5, 2020 1:55 AM
To: Thomas,Renish 
Cc: arts users mi 
Subject: Re: Fwd: Re: [arts-users] ARTS internally generated PND fields

Renish,

Are you doing full calculations, running eg DISORT? If yes, then setting the 
input to
pnd_agenda should be automatic.

Or are you trying to use the PSD functions separately?

Can you clarify this before I try to answer? And maybe also send me your 
control file.

Bye,

Patrick


> *Från:* "Thomas,Renish" 
> *Skickat:* 4 december 2020 16:40:25 CET
> *Till:* Patrick Eriksson ,
> "arts_users.mi@lists.uni-hamburg.de" 
> 
> *Ämne:* Re: [arts-users] ARTS internally generated PND fields
>
> Hi Patrick/ Everyone,
>
> Thanks, for the inputs .
> I was able to clear some of the errors.
>
> I have a couple more questions. It will be great to have some input on these.
>
> 1.)  How do I set "pnd_agenda_input_t"?. Is the name "Temperature" in bulk 
> prop fields
> names enough to set this, or should I set this explicitly?
>
> 2.) Can the particle temperature be different from the atmosphere temperature 
> around it?
>
> 3.) I have no problems with running psdModifiedGammaMass, while running it. 
> But while
> running psdModifiedGammaMassXmean, I get this error.
>
> Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
> error: Run-time
> error in agenda: pnd_agenda_array
> Run-time error in method: psdModifiedGammaMassXmean
> Negative mean sizefound.
> This is not allowed.
>
> My inputs are
> Dmean = 1e-3.
> n0 = -999
> mu = 2
> la = -999
> ga = 1
>
> Could I know why this error occours ?
>
> Cheers,
> Renish
> --
> *From:* Patrick Eriksson 
> *Sent:* Thursday, November 19, 2020 11:47 AM
> *To:* Thomas,Renish ; 
> arts_users.mi@lists.uni-hamburg.de
> 
> *Subject:* Re: [arts-users] ARTS internally generated PND fields
> Hi Renish,
>
> Yes, this part is a complex and could need some more examples. However,
> this part will be modified in a big overhaul of the handling of
> scattering properties that Simon is working on and this makes us all a
> bit reluctant to add examples right now.
>
>
>> 1.)  So, the "Mass_content" , "Xmean" and "Temperature" are the only
>> fields that I need to provide in the particle_bulkprop_field?
>
> This depends on the PSDs you are using. In TestScatSolvers.arts this
> field holds IWC and RWC, which are sufficient for the selected PSDs, but
> if you want to use psdModifiedGammaMassXmean, you need to include data
> on the mean size.
>
>
>> 2.) Do I need to set the pnd_agenda_input manually , or does it take
>> values from the Bulkprop_fields?
>
> No, but you need to link the naming in particle_bulkprop_field to the
> pnd_agenda_input. In your case it could look this
>
> ArrayOfStringSet( pnd_agenda_input_names, [ "IWC", "Dmean" ]
>
>
>> 3.)  Are there other examples for this method that I can refer to?
>
> Which method? (But the answer is likely anyhow no)
>
>> 4.) Also, when I run the example "TestScatSolvers.arts" modified to use
>> PSD from psdModifiedGammaMassXmean(). I get this error
>>
>> Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed
>> with error: *scat_data* and *scat_species* are inconsistent in size.
>
> The scattering data in TestScatSolvers.arts cover both IWC and RWC. if
> you have changed and just work with one hydrometeor type, you need to
> modify the scattering data accordingly.
>
> I hope this was of some help,
>
> Patrick
<>
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

Re: [arts-users] ARTS internally generated PND fields

[Thomas,Renish]

Hi Patrick/ Everyone,

Thanks, for the inputs .
I was able to clear some of the errors.

I have a couple more questions. It will be great to have some input on these.

1.)  How do I set "pnd_agenda_input_t"?. Is the name "Temperature" in bulk prop 
fields names enough to set this, or should I set this explicitly?

2.) Can the particle temperature be different from the atmosphere temperature 
around it?

3.) I have no problems with running psdModifiedGammaMass, while running it. But 
while running psdModifiedGammaMassXmean, I get this error.

Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
error: Run-time error in agenda: pnd_agenda_array
Run-time error in method: psdModifiedGammaMassXmean
Negative mean sizefound.
This is not allowed.

My inputs are
Dmean = 1e-3.
n0 = -999
mu = 2
la = -999
ga = 1

Could I know why this error occours ?

Cheers,
Renish

From: Patrick Eriksson 
Sent: Thursday, November 19, 2020 11:47 AM
To: Thomas,Renish ; 
arts_users.mi@lists.uni-hamburg.de 
Subject: Re: [arts-users] ARTS internally generated PND fields

Hi Renish,

Yes, this part is a complex and could need some more examples. However,
this part will be modified in a big overhaul of the handling of
scattering properties that Simon is working on and this makes us all a
bit reluctant to add examples right now.


> 1.)  So, the "Mass_content" , "Xmean" and "Temperature" are the only
> fields that I need to provide in the particle_bulkprop_field?

This depends on the PSDs you are using. In TestScatSolvers.arts this
field holds IWC and RWC, which are sufficient for the selected PSDs, but
if you want to use psdModifiedGammaMassXmean, you need to include data
on the mean size.


> 2.) Do I need to set the pnd_agenda_input manually , or does it take
> values from the Bulkprop_fields?

No, but you need to link the naming in particle_bulkprop_field to the
pnd_agenda_input. In your case it could look this

ArrayOfStringSet( pnd_agenda_input_names, [ "IWC", "Dmean" ]


> 3.)  Are there other examples for this method that I can refer to?

Which method? (But the answer is likely anyhow no)

> 4.) Also, when I run the example "TestScatSolvers.arts" modified to use
> PSD from psdModifiedGammaMassXmean(). I get this error
>
> Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed
> with error: *scat_data* and *scat_species* are inconsistent in size.

The scattering data in TestScatSolvers.arts cover both IWC and RWC. if
you have changed and just work with one hydrometeor type, you need to
modify the scattering data accordingly.

I hope this was of some help,

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

[arts-users] ARTS internally generated PND fields

[Thomas,Renish]

Hi Everyone,

I had a couple of questions about generating PND fields internally for 
scattering

The only example that I could find are in 
"artscomponents/scatsolvercomp/TestScatSolvers.arts"
which uses the method 
pnd_fieldCalcFromParticleBulkProps
 . I intend to use this with the PSD generator method 
psdModifiedGammaMassXmean()

So, my questions are:

1.)  So, the "Mass_content" , "Xmean" and "Temperature" are the only fields 
that I need to provide in the particle_bulkprop_field?

2.) Do I need to set the pnd_agenda_input manually , or does it take values 
from the Bulkprop_fields?

3.)  Are there other examples for this method that I can refer to?

4.) Also, when I run the example "TestScatSolvers.arts" modified to use PSD 
from psdModifiedGammaMassXmean(). I get this error

Exception: Call to ARTS WSM pnd_fieldCalcFromParticleBulkProps failed with 
error: *scat_data* and *scat_species* are inconsistent in size.

Cheers,
Renish





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

Re: [arts-users] arts_users.mi Digest, Vol 53, Issue 1

[Thomas,Renish]

Thank You all for the suggestions.

Yeah, I tried the recommendations and see that the brightness temperatures 
change a lot between the models especially near the water vapor absorption 
lines.

Cheers,
Renish



From: arts_users.mi-boun...@lists.uni-hamburg.de 
 on behalf of Stefan Buehler 

Sent: Monday, November 16, 2020 9:21 AM
To: Fox, Stuart 
Cc: arts_users.mi@lists.uni-hamburg.de ; 
Oleksandr Bobryshev 
Subject: Re: [arts-users] arts_users.mi Digest, Vol 53, Issue 1

Dear Renish,

yes, these are good points by Stuart. The metmm setup is not optimized
for the oxygen bands. My understanding is that Alex, here in Cc, is
currently testing the different oxygen setups. Alex, perhaps you could
also comment?

For the water vapor, note that Alex also made tweaks to some line
parameters according to recent literature (at the time, as described in
the README file). The reason to stick with that setup would be because
it has been compared to observations. I can’t say about the newer
HITRAN and CKDMT320. It may be equally good or even better. But not
necessarily. That’s a bit the problem with these recommendations
it’s a bit of a moving target.

Best wishes,

Stefan

On 12 Nov 2020, at 12:15, Fox, Stuart wrote:

> Hi Renish/Stefan,
>
> Looking at the controlfile Stefan recommends I have a couple of
> concerns/questions. Firstly, it looks to me that the Oxygen absorption
> set-up is using line parameters from the catalog file (which I'm
> assuming is HITRAN-2012?), but does not have any line mixing. I would
> expect this to lead to problems in the 50-60GHz oxygen band and have
> an impact out into the 89GHz window region. My understanding was that
> it was simplest to use the "O2-TRE05" complete absorption model for
> oxygen which does include the line mixing effects?
>
> The water vapour set-up is probably fine, although my preference is to
> use the values from the AER catalog which has a couple of tweaks to
> better fit some atmospheric observations. I think the recent releases
> are almost the same as HITRAN-2016, but maybe not HITRAN-2012? Recent
> versions of ARTS also have the CKDMT320 continuum (courtesy of Emma
> Turner) and I've found that seems to give a reasonable match to much
> of our airborne data.
>
> Regards,
>
> Stuart
>
> -Original Message-
> From: arts_users.mi-boun...@lists.uni-hamburg.de
>  On Behalf Of
> arts_users.mi-requ...@lists.uni-hamburg.de
> Sent: 12 November 2020 11:00
> To: arts_users.mi@lists.uni-hamburg.de
> Subject: arts_users.mi Digest, Vol 53, Issue 1
>
> This email was received from an external source.   Always check sender
> details, links & attachments.
>
> Send arts_users.mi mailing list submissions to
>arts_users.mi@lists.uni-hamburg.de
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=04%7C01%7Crenish.thomas%40colostate.edu%7C550d6642fad64142a13808d88a4bb20c%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C1%7C637411405014479246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X4a%2FGMB5rcly0hPokw3%2BmFDo6KJOo%2B5VKeWyZ39NYgc%3D&reserved=0
> or, via email, send a message with subject or body 'help' to
>arts_users.mi-requ...@lists.uni-hamburg.de
>
> You can reach the person managing the list at
>arts_users.mi-ow...@lists.uni-hamburg.de
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of arts_users.mi digest..."
>
>
> Today's Topics:
>
>1. Choosing the right Continua models/spectroscopy data
>   (Thomas,Renish)
>2. Re: Choosing the right Continua models/spectroscopy data
>   (Stefan Buehler)
>
>
> --
>
> Message: 1
> Date: Thu, 12 Nov 2020 04:13:56 +
> From: "Thomas,Renish" 
> To: "arts_users.mi@lists.uni-hamburg.de"
>
> Subject: [arts-users] Choosing the right Continua models/spectroscopy
>data
> Message-ID:
>
> 
>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hi Everyone,
>
> I had a question about selecting the best Continua models/spectroscopy
> lines for the most accurate simulation results.
>
> My main species of interest is "H2O" and I am simulating an airborne
> sensor. The difference in brightness temperatures when I use the
> "H2O-PWR98" vs. "H2O" lines from the Perrin database along with the
> PWR98 model is greater than about 10 degrees around the 183 GHz water
>

[arts-users] Choosing the right Continua models/spectroscopy data

[Thomas,Renish]

Hi Everyone,

I had a question about selecting the best Continua models/spectroscopy lines 
for the most accurate simulation results.

My main species of interest is "H2O" and I am simulating an airborne sensor. 
The difference in brightness temperatures when I use the "H2O-PWR98" vs. "H2O" 
lines from the Perrin database along with the PWR98 model is greater than about 
10 degrees around the 183 GHz water vapor lines.

So, my question is, what is the best strategy on choosing the continua models 
and spectroscopic data around the absorption lines and in the window region 
(Away from absorption lines).

My region of interest is 50-300 GHz.

Also, what are the recommended spectroscopic lines and for what applications 
are they most suited for. Example : Perrins, HITRAN.

Cheers,
Renish

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

[arts-users] RJBT vs PlanckBT units

[Thomas,Renish]

Hi Everyone,

I had a question about when to use RJBT vs PlanckBT for "iy unit", to get 
observed brightness temperatures.

I assume the difference between using the two methods should be very minimal in 
the microwave region. In some situations, especially looking through a long 
path through the atmosphere, I get about 2 - 3 K of difference in the 
200-300GHz range. Is this expected.

Cheers,
Renish
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

Re: [arts-users] IWP in ARTS

[Thomas,Renish]

Thanks Simon,

I really appreciate the advice.

I had further questions about the more appropriate choice between using the 
pyARTS and Typhon  python packages for ARTS.

My simulation setup ( Predominantly ):

I am trying to sense a cloud box (ON/OFF) , with the sensor looking forward. 
(i.e elevation 0 degrees). I will be wanting to perform both absorption and 
scattering calculations.

My questions:

a).  Which one is more appropriate for my application between pyARTS and Typhon.

b). Do pyARTS and Typhon share mostly the same functions and libraries and are 
they inter-compatible?. Which of these are better documented?


Thanks,
Renish



From: Simon Pfreundschuh 
Sent: Friday, August 14, 2020 12:24 AM
To: Patrick Eriksson ; Thomas,Renish 
; arts_users.mi@lists.uni-hamburg.de 

Subject: Re: [arts-users] IWP in ARTS


Hi Renish,


I have to correct Patrick here, pyarts has been revived and is now the official 
Python

interface for ARTS. To use the Python interface you have two options:


  1.  Build the ARTS development version and the install the pyarts package in 
the python directory
  2.  Install pyarts using pip

Option 1 has the advantage of installing also the ARTS interpreter itself, i.e. 
the arts command
line program as well as the example files, which could help you to get started. 
With option two
you will be able to use ARTS only through the Python interface.


Hope this helps to get you started. Don't hesitate to contact me if you have 
any other

questions.

Best,

Simon

From: arts_users.mi-boun...@mailman.rrz.uni-hamburg.de 
 on behalf of Patrick 
Eriksson 
Sent: Thursday, August 13, 2020 11:21:03 PM
To: Thomas,Renish; arts_users.mi@lists.uni-hamburg.de
Subject: Re: [arts-users] IWP in ARTS

Hi,

If you are familiar with python, or want to be, I recommend that you
switch to it. In python you have access to a proper interface to ARTS,
and you can run it truly interactively. And you can get more help. I am
the only one of the core developers that still is using matlab.

It is then Typhon ypu should look at. Not PyARTS, it's old.

Bye,

Patrick



On 2020-08-13 21:12, Thomas,Renish wrote:
> Thanks Patrick for the clarification,
>
> I saw one of the Atmlab scattering demo examples which uses IWP as an
> input, which later is converted to PND (Partcile Number Density) before
> calling ARTS.
>
> I am still trying to use Atmlab for scattering calculations with
> particle size distributions with a cloud box, due to the ease of using
> Matlab.
>
> Do  you recommend a better way? like PyARTS or using ARTS by itself for
> scattering calculations?
>
> Thanks,
> Renish Thomas
>
>
> 
> *From:* Patrick Eriksson 
> *Sent:* Tuesday, August 11, 2020 8:29 AM
> *To:* Thomas,Renish ;
> arts_users.mi@lists.uni-hamburg.de
> 
> *Subject:* Re: [arts-users] IWP in ARTS
> Dear Renish,
>
> ARTS does not take IWP, TWP etc as input. You need to specify e.g. IWC,
> LWC, humidity ...
>
> And the specification of the atmospheric profiles is independent of the
> observation geometry. You specify the profiles as a function of pressure.
>
> Not clear how you are running ARTS by Atmlab. Please note that qarts
> (and qpack even less) is mainly for calculations without scattering. You
> can do scattering calculations but then you really need to know how ARTS
> is working.
>
> Bye,
>
> Patrick
>
>
>
>
> On 2020-08-10 22:22, Thomas,Renish wrote:
>> Hi All,
>>
>> I had a question about how ARTS treats integrated water path ( IWP ).
>>
>> *My simulation setup*:
>>
>> I am trying to sense a cloud box , with the sensor looking forward. (i.e
>> elevation 0 degrees). I am using ARTS with Atmlab.
>>
>> *My questions:*
>>
>> *a). *How to calculate IWP/LWP (which is an input for ARTS) for the case
>> of horizontal sounding of an extended cloud. Or how to use droplet
>> density as an input instead of IWP.
>>
>> *b). *Can i give IWP as an input for all elevations?  Does the radiative
>> transfer calculations in these cases behave properly for off zenith and
>> off nadir look angles.
>>
>> As i believe  LWP = TPW for the case of nadir-zenith sensing of an
>> entire atmosphere.
>>
>>
>> *LWP*(Liquid Water Path)
>> *TPW*(Total Precipitable Water)
>>
>> Cheers,
>> Renish
>>
>>
>>
>> ___
>> arts_users.mi mailing list
>> arts_users.mi@lists.uni-hamburg.de
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=02%7C01%7CRenish.Tho

Re: [arts-users] IWP in ARTS

[Thomas,Renish]

Thanks Patrick for the clarification,

I saw one of the Atmlab scattering demo examples which uses IWP as an input, 
which later is converted to PND (Partcile Number Density) before calling ARTS.

I am still trying to use Atmlab for scattering calculations with particle size 
distributions with a cloud box, due to the ease of using Matlab.

Do  you recommend a better way? like PyARTS or using ARTS by itself for 
scattering calculations?

Thanks,
Renish Thomas



From: Patrick Eriksson 
Sent: Tuesday, August 11, 2020 8:29 AM
To: Thomas,Renish ; 
arts_users.mi@lists.uni-hamburg.de 
Subject: Re: [arts-users] IWP in ARTS

Dear Renish,

ARTS does not take IWP, TWP etc as input. You need to specify e.g. IWC,
LWC, humidity ...

And the specification of the atmospheric profiles is independent of the
observation geometry. You specify the profiles as a function of pressure.

Not clear how you are running ARTS by Atmlab. Please note that qarts
(and qpack even less) is mainly for calculations without scattering. You
can do scattering calculations but then you really need to know how ARTS
is working.

Bye,

Patrick




On 2020-08-10 22:22, Thomas,Renish wrote:
> Hi All,
>
> I had a question about how ARTS treats integrated water path ( IWP ).
>
> *My simulation setup*:
>
> I am trying to sense a cloud box , with the sensor looking forward. (i.e
> elevation 0 degrees). I am using ARTS with Atmlab.
>
> *My questions:*
>
> *a). *How to calculate IWP/LWP (which is an input for ARTS) for the case
> of horizontal sounding of an extended cloud. Or how to use droplet
> density as an input instead of IWP.
>
> *b). *Can i give IWP as an input for all elevations?  Does the radiative
> transfer calculations in these cases behave properly for off zenith and
> off nadir look angles.
>
> As i believe  LWP = TPW for the case of nadir-zenith sensing of an
> entire atmosphere.
>
>
> *LWP*(Liquid Water Path)
> *TPW*(Total Precipitable Water)
>
> Cheers,
> Renish
>
>
>
> ___
> arts_users.mi mailing list
> arts_users.mi@lists.uni-hamburg.de
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.rrz.uni-hamburg.de%2Fmailman%2Flistinfo%2Farts_users.mi&data=02%7C01%7CRenish.Thomas%40colostate.edu%7Cea619cb0a1254d6e42bd08d83e02fa22%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637327529808522851&sdata=m0jOTRKuv3eygwPpqAQa7l00E0%2BnARJc7MDSGpiZZTk%3D&reserved=0
>
___
arts_users.mi mailing list
arts_users.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi

[arts-users] IWP in ARTS

[Thomas,Renish]

Hi All,

I had a question about how ARTS treats integrated water path ( IWP ).

My simulation setup:

I am trying to sense a cloud box , with the sensor looking forward. (i.e 
elevation 0 degrees). I am using ARTS with Atmlab.

My questions:

a).  How to calculate IWP/LWP (which is an input for ARTS) for the case of 
horizontal sounding of an extended cloud. Or how to use droplet density as an 
input instead of IWP.

b). Can i give IWP as an input for all elevations?  Does the radiative transfer 
calculations in these cases behave properly for off zenith and off nadir look 
angles.

As i believe  LWP = TPW for the case of nadir-zenith sensing of an entire 
atmosphere.


LWP (Liquid Water Path)
TPW (Total Precipitable Water)

Cheers,
Renish


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

[arts-users] Pressure field ambiguity

[Thomas,Renish]

Hi All,


I have a question regarding the pressure grid in Atmlab fields. So I 
see in the demo examples that pressure fields can be inputted using the 
Q.RAW_ATMOSPHERE and also there is a field called Q.P_GRID. Which of these 
pressure fields is ultimately used for calculations? or do they mean two  
different things?




Thanks,
Renish Thomas,


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