Re: Help, something broke my simulations!
Hi Stuart, This is a bug! The read methods should all reset their target. Your original controlfile was correct. I will immediately commit some code to fix this. I hope to have it merged by tomorrow morning. //Richard Den tors 17 mars 2022 kl 16:23 skrev Fox, Stuart < stuart@metoffice.gov.uk>: > Hi Richard, > > > > I think I have now tracked down the source of my issue (and identified the > fix)! > > > > It seems there has been a change to the way that ReadARTSCAT works? > Previously it looks like it re-initialised the abs_lines variable each time > it was called, whereas now it appears to append onto the end of the > existing variable. Since I am reading separate line files for H2O and O3 > the way I was approaching this was: > > ArrayOfAbsorptionLinesCreate(temp_lines) > > ReadARTSCAT(filename="aer_3.6_lines_0_5THz.H2O.xml.gz", > > abs_lines=temp_lines, > > …) > > Append(abs_lines, temp_lines) > > ReadARTSCAT(filename="JPL_fast.O3.xml.gz", > > abs_lines=temp_lines, > > …) > > Append(abs_lines, temp_lines) > > > > Using the new behaviour I can either just use two calls to ReadARTSCAT to > read directly into abs_lines (assuming this is actually the intended > behaviour?), or reset temp_lines between the two calls. Without this then, > as suspected, it adds the H2O lines twice. > > > > Does this make sense? > > > > Stuart > > > > *From:* Richard Larsson > *Sent:* 17 March 2022 13:13 > *To:* Fox, Stuart > *Subject:* Re: Help, something broke my simulations! > > > > *This email was received from an external source. Always check sender > details, links & attachments.* > > Hi Stuart, > > > > Can you do workspace.Print(workspace.abs_lines_per_species)? If you have > the mirrored lines, then they should be there, towards the end of the water > tag. (It might be better to access these from the > workspace.abs_lines_per_species.value if you have too many lines. > workspace.abs_lines_per_species.value[N][M].lines [or something like that] > should give you the lines of the M+1:th band of your N+1:th abs_species > tag. The last of these for water should have negative values.) > > > > (I think it would be better to set the mirroring tag to something like > Lorentz using workspace.abs_lines_per_speciesSetMirroringForSpecies, since > this should be the physically correct way of doing it.) > > > > //Richard > > > > Den tors 17 mars 2022 kl 12:50 skrev Fox, Stuart < > stuart@metoffice.gov.uk>: > > Hi Richard, > > > > I really don’t think there’s a copy/paste error – I am running exactly the > same set of instructions (via pyarts) and I get the different results > between the different ARTS versions. > > > > Propmat_clearsky_agenda is: > >workspace.propmat_clearskyInit() > > workspace.propmat_clearskyAddXsecAgenda() > > workspace.propmat_clearskyAddLines() > > workspace.propmat_clearskyAddPredefined() > > and abs_xsec_agenda is: > > workspace.abs_xsec_per_speciesInit() > > workspace.abs_xsec_per_speciesAddConts() > > > > Have you changed abs_lines_per_speciesMakeManualMirroringSpecies? (I am > using this for the water vapour but not the ozone)? > > > > I will look at putting together a simpler test case… > > > > Stuart > > *From:* Richard Larsson > *Sent:* 17 March 2022 11:30 > *To:* Fox, Stuart > *Cc:* arts_dev.mi@lists.uni-hamburg.de > *Subject:* Re: Help, something broke my simulations! > > > > *This email was received from an external source. Always check sender > details, links & attachments.* > > Hi Stuart, > > > > I would need some way to test this to give any real answers. For now I > can only ask questions. > > > > It looks like you are somehow computing the 183 GHz line twice. This > should not happen easily. Have you somehow made a copy-paste error that > still retains a "complete" model in this setup? > > > > Are you using abs_xsec_per_speciesAddLines or propmat_clearskyAddLines? > (It would be fantastic if you are using both, because then the error would > be exactly that, but your ozone lines make it look like you are not > computing them twice.) > > > > There are some small changes in abs_xsec_per_speciesAddLines. I don't > think they should cause any issues, but change is change so it is a > possibility. > > > > With hope, > > //Richard > > > > Den tors 17 mars 2022 kl 11:57 skrev Fox, Stuart <
RE: Help, something broke my simulations!
Hi Richard, I think I have now tracked down the source of my issue (and identified the fix)! It seems there has been a change to the way that ReadARTSCAT works? Previously it looks like it re-initialised the abs_lines variable each time it was called, whereas now it appears to append onto the end of the existing variable. Since I am reading separate line files for H2O and O3 the way I was approaching this was: ArrayOfAbsorptionLinesCreate(temp_lines) ReadARTSCAT(filename="aer_3.6_lines_0_5THz.H2O.xml.gz", abs_lines=temp_lines, …) Append(abs_lines, temp_lines) ReadARTSCAT(filename="JPL_fast.O3.xml.gz", abs_lines=temp_lines, …) Append(abs_lines, temp_lines) Using the new behaviour I can either just use two calls to ReadARTSCAT to read directly into abs_lines (assuming this is actually the intended behaviour?), or reset temp_lines between the two calls. Without this then, as suspected, it adds the H2O lines twice. Does this make sense? Stuart From: Richard Larsson Sent: 17 March 2022 13:13 To: Fox, Stuart Subject: Re: Help, something broke my simulations! This email was received from an external source. Always check sender details, links & attachments. Hi Stuart, Can you do workspace.Print(workspace.abs_lines_per_species)? If you have the mirrored lines, then they should be there, towards the end of the water tag. (It might be better to access these from the workspace.abs_lines_per_species.value if you have too many lines. workspace.abs_lines_per_species.value[N][M].lines [or something like that] should give you the lines of the M+1:th band of your N+1:th abs_species tag. The last of these for water should have negative values.) (I think it would be better to set the mirroring tag to something like Lorentz using workspace.abs_lines_per_speciesSetMirroringForSpecies, since this should be the physically correct way of doing it.) //Richard Den tors 17 mars 2022 kl 12:50 skrev Fox, Stuart mailto:stuart@metoffice.gov.uk>>: Hi Richard, I really don’t think there’s a copy/paste error – I am running exactly the same set of instructions (via pyarts) and I get the different results between the different ARTS versions. Propmat_clearsky_agenda is: workspace.propmat_clearskyInit() workspace.propmat_clearskyAddXsecAgenda() workspace.propmat_clearskyAddLines() workspace.propmat_clearskyAddPredefined() and abs_xsec_agenda is: workspace.abs_xsec_per_speciesInit() workspace.abs_xsec_per_speciesAddConts() Have you changed abs_lines_per_speciesMakeManualMirroringSpecies? (I am using this for the water vapour but not the ozone)? I will look at putting together a simpler test case… Stuart From: Richard Larsson mailto:ric.lars...@gmail.com>> Sent: 17 March 2022 11:30 To: Fox, Stuart mailto:stuart@metoffice.gov.uk>> Cc: arts_dev.mi@lists.uni-hamburg.de<mailto:arts_dev.mi@lists.uni-hamburg.de> Subject: Re: Help, something broke my simulations! This email was received from an external source. Always check sender details, links & attachments. Hi Stuart, I would need some way to test this to give any real answers. For now I can only ask questions. It looks like you are somehow computing the 183 GHz line twice. This should not happen easily. Have you somehow made a copy-paste error that still retains a "complete" model in this setup? Are you using abs_xsec_per_speciesAddLines or propmat_clearskyAddLines? (It would be fantastic if you are using both, because then the error would be exactly that, but your ozone lines make it look like you are not computing them twice.) There are some small changes in abs_xsec_per_speciesAddLines. I don't think they should cause any issues, but change is change so it is a possibility. With hope, //Richard Den tors 17 mars 2022 kl 11:57 skrev Fox, Stuart mailto:stuart@metoffice.gov.uk>>: Hi ARTS devs, One of the recent-(ish) commits to ARTS has broken my simulations! With the current head of master I get big differences in simulated brightness temperature around a water vapour absorption line when I do simulations that also include ozone (blue line in attached plots), compared to simulations without (orange line). This didn’t use to be the case, at least back at commit 3b6565f. Both water vapour and ozone in these simulations are calculated using absorption line catalogues rather than “complete” models – if I use a complete model for water vapour the problem goes away. Before I spend a bit of time putting together a simple test case and/or trying to identify which commits caused the change, does anyone know already what the cause might be, and what I need to do to fix it (e.g. changes to controlfiles)? Regards, Stuart
Re: Help, something broke my simulations!
Hi Stuart, I would need some way to test this to give any real answers. For now I can only ask questions. It looks like you are somehow computing the 183 GHz line twice. This should not happen easily. Have you somehow made a copy-paste error that still retains a "complete" model in this setup? Are you using abs_xsec_per_speciesAddLines or propmat_clearskyAddLines? (It would be fantastic if you are using both, because then the error would be exactly that, but your ozone lines make it look like you are not computing them twice.) There are some small changes in abs_xsec_per_speciesAddLines. I don't think they should cause any issues, but change is change so it is a possibility. With hope, //Richard Den tors 17 mars 2022 kl 11:57 skrev Fox, Stuart < stuart@metoffice.gov.uk>: > Hi ARTS devs, > > > > One of the recent-(ish) commits to ARTS has broken my simulations! With > the current head of master I get big differences in simulated brightness > temperature around a water vapour absorption line when I do simulations > that also include ozone (blue line in attached plots), compared to > simulations without (orange line). This didn’t use to be the case, at least > back at commit 3b6565f. Both water vapour and ozone in these simulations > are calculated using absorption line catalogues rather than “complete” > models – if I use a complete model for water vapour the problem goes away. > > > > Before I spend a bit of time putting together a simple test case and/or > trying to identify which commits caused the change, does anyone know > already what the cause might be, and what I need to do to fix it (e.g. > changes to controlfiles)? > > > > Regards, > > > > Stuart >
Help, something broke my simulations!
Hi ARTS devs, One of the recent-(ish) commits to ARTS has broken my simulations! With the current head of master I get big differences in simulated brightness temperature around a water vapour absorption line when I do simulations that also include ozone (blue line in attached plots), compared to simulations without (orange line). This didn't use to be the case, at least back at commit 3b6565f. Both water vapour and ozone in these simulations are calculated using absorption line catalogues rather than "complete" models - if I use a complete model for water vapour the problem goes away. Before I spend a bit of time putting together a simple test case and/or trying to identify which commits caused the change, does anyone know already what the cause might be, and what I need to do to fix it (e.g. changes to controlfiles)? Regards, Stuart
