Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

saturation vapor pressure table overflow #270

Open
YueXu-pku-ucsd opened this issue Sep 13, 2024 · 2 comments
Open

saturation vapor pressure table overflow #270

YueXu-pku-ucsd opened this issue Sep 13, 2024 · 2 comments

Comments

@YueXu-pku-ucsd
Copy link

I need to run ISCA under >600 ppm CO2 condition, but it crashes before reaching equilibrium due to the temperature exceeding the range. Simply increasing the temperature range results in a ‘saturation vapor pressure table overflow’ issue. However, our research requires the presence of water vapor, so we can’t turn it off. How should we resolve this situation? We welcome technical experts to join our research and provide technical support.

@matthewjhenry
Copy link
Contributor

Hi,
The 'saturation vapor pressure table overflow' is the symptom of a model blowup, rather than it being anything to do with actual water vapor.
You can try the fix from the screenshot attached or reduce the timestep (dt_atmos=360 e.g.).
Hope that helps,
-Matthew
Screenshot 2021-10-27 at 11 57 19

@ntlewis
Copy link
Contributor

ntlewis commented Sep 20, 2024

I just wanted to note that I don’t entirely agree with this comment. The min and max bounds on the vapor pressure table are there because (i) for the simple case, the analytic fit to Clausius clayperon becomes less good at temperatures far from (es0, T0), and (ii) for the ‘full’ look up table, I think the min and max are related to the tabulated temperatures vs. esat. Obviously, I agree that one reason that the temperatures can become too large / small is because the model is crashing.

Unfortunately, I don’t have time to right a full reply, as I’m about to go on holiday for 2 weeks.

However, if the model is just ‘crashing anyway’, I agree that reducing the time step could help. In this scenario, changing the tcmin and tcmax (or tcmin_simple and tcmax_simple if do_simple=True) wouldn’t actually prevent the crash, instead the model would crash with a different error (for example, something like ‘temperatures outside of valid range’).

If the issue is directly caused by the bounds on the saturation vapour pressure calculation, then you can extend them, as Matthew has suggested. However, you should ensure that the values for esat being returned are actually sensible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants