You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In running the Proga models, Nick wanted to try a case where he calculated the ionization with only a central component. But for spectra he wanted to add disk emission. So he tried adding a disk component to a parameter file and restarting the model for additional spectral cycles. He found that although the model ran, no disk photons were produced. Knox confirmed this with some very simple SV models.
Some checking with DDD shows that the problem arises in python.c because when the old wind file is read in around line 565, geo.wind_mdot is read in as zero. [I do not really know why this is; geo is written out by the first program and read in in this program. One would have thought it would have been whatever I set it to in the first .pf file and it was not that.) Furthermore, reading geo.disk_mdot is skipped (because of statement at line 868).
Later on there is a check to see whether whether, disk_mdot is zero, and if it is then disk radiation is turned off.
What should we do about this? The software is a bit of a mess here. The intent was when you read in an old windfile to prevent you from doing anything silly, like changing the wind dimensions. But this means that the python code is complicated. It looks like a solution is to reexamine which variables are read in from the .pf file, and adjust python.c accordingly.
We need to document this well, because this is an area of the code that will continue to change as we add new features.
The text was updated successfully, but these errors were encountered:
The fundamental issue here seems to be that the parameter geo.disk_mdot is set to zero at line 937 if there is no disk radiation required. This means that this value get written out to the windsave file, and therefore read in later.
This is one of the parameters that is not read in on restart - possibly fair enough - but the fact that this is set to zero is used to turn off disk radiation at line 1296.
The obvious solution to this particular problem is to simply remove the if statements around line 920 - so even if there is no disk radiation, we still read in the disk parameters.
This certainly fixes the initial problem, but I need to check for unintended consequences!
Of course the downside of just commenting out this if loop is that even if you say you dont want disk radiation - you still have to define the disk....
Hmmmm
If you want to do this, you have to specify the disk properties but turn disk radiation off. It's a fairly obscure thing to want to do anyway, but this works!
In running the Proga models, Nick wanted to try a case where he calculated the ionization with only a central component. But for spectra he wanted to add disk emission. So he tried adding a disk component to a parameter file and restarting the model for additional spectral cycles. He found that although the model ran, no disk photons were produced. Knox confirmed this with some very simple SV models.
Some checking with DDD shows that the problem arises in python.c because when the old wind file is read in around line 565, geo.wind_mdot is read in as zero. [I do not really know why this is; geo is written out by the first program and read in in this program. One would have thought it would have been whatever I set it to in the first .pf file and it was not that.) Furthermore, reading geo.disk_mdot is skipped (because of statement at line 868).
Later on there is a check to see whether whether, disk_mdot is zero, and if it is then disk radiation is turned off.
What should we do about this? The software is a bit of a mess here. The intent was when you read in an old windfile to prevent you from doing anything silly, like changing the wind dimensions. But this means that the python code is complicated. It looks like a solution is to reexamine which variables are read in from the .pf file, and adjust python.c accordingly.
We need to document this well, because this is an area of the code that will continue to change as we add new features.
The text was updated successfully, but these errors were encountered: