-
Notifications
You must be signed in to change notification settings - Fork 52
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 solves fail moving from 0.5.7 to 0.5.8 #237
Comments
It's worth noting we're not using the default initial guess during our iterations as well |
Hmm, there was an update to increase accuracy on x0_sat_pure, but if it causes this, it needs to be reverted |
@lucpaoli hmmm, i'm afraid i would need that initial point, we did add an stricter check here: Clapeyron.jl/src/methods/property_solvers/singlecomponent/saturation/saturation.jl Lines 77 to 88 in 758d5ce
so if pressures deviate significantly, then it would fail instead of giving an incorrect result |
this would be solved on 0.5.10 (the check was done at the solver level instead) |
Hey all,
With the update from 0.5.7 to 0.5.8, the saturation solver as we're using it seems to have become less robust, frequently breaking during iterations.
If you look on the SAFT_ML github page (which I think you all have access to), the difference can be seen in the output log between the runs in 22_tests vs the runs in 23_updated_Clapeyron, where "updated_Clapeyron" refers to us downgrading from 0.5.8. to 0.5.7.
I'm afraid I don't have any time to try to validate a minimum working example right now, but an example case where it was failing on for us is:
Sat solver failed for heptacosane = [380.44, 2.0, 3.0, 6.0, 20.01, 200.51] at T=94.33, Tc=266.06, muting...
where those parameters are input into SAFT VR Mie.
The text was updated successfully, but these errors were encountered: