HELD Issue tracker

[pw0908]

Just a list of things we need to fix in our implementation of the HELD algorithm:

• Rather than use randomly generated points for initial guesses in step 1 and step 4, use sobol points
• Fix the convergence issue with VLE phases
• Loop step 8 to step 3
• log-compositions on step 7?
• Try using BlackBoxOptim for step 4 and 7 instead of NLSolvers
• Recommendation: Solve step 4 multiple times to generate as many candidate phase as possible. Could speed up convergence?
• Use tunnelling in step 4? To avoid repeated solutions?

[ianhbell]

Does this mean that the HELD implementation is making good progress? I am very happy to hear that.

[longemen3000]

in particular this branch https://github.com/ypaul21/Clapeyron.jl/tree/HELD_TP contains the current HELD Tp-flash implementation

[longemen3000]

notes about the SRK test in the HELD paper:
k = 0.08
the test is at 4.053 Mpa (40 atm), not 4.53. they cite (https://doi.org/10.1016/S0098-1354(02)00144-8) where the value appears. (the description of the eos does mention 40 atm, but the table has a typo)

[branch171]

I have started to implement a robust version of HELD that I will provide to Clapeyron once it is complete. Some important observations. You need a robust optimisation algorithm based on trust region method with a projection operator to limit the trust region radius at each step so that the step is feasible in terms of mole fractions being in the range 0 to 1 and the implicit mole fraction (nc) is likewise. The current unbounded optimisations used are not robust in this regard. With this implemented there is some book keeping to ensure that the correct number of phases are selection on termination this requires that the system should mole balance. Its also important to reject trivial solutions, i.e. the feed composition for the optimisation as these routinely appear but if we have an unstable phase they can only appear if we are on a phase boundary like bubble or dew point and this need to be diagnosed. I would say that HELD is extremely robust even with local based optimisation but does not scale well with numbers of components.

[ianhbell]

That's exciting! I am interested in porting to teqp as well to serve as our backup flash algorithm when things don't go properly. Good to have a slow-and-steady routine to fall back on.

[pw0908]

Hi @branch171! Really exciting that you're able to get HELD to work! Did you take a look at our implementation on the HELD_TP branch?

In terms of non-linear optimization solvers, have you contacted the folks at NLSolvers.jl? They have a lot of non-linear solvers and this sounds like it could easily be incorporated into their package.

[branch171]

Yes I went trough the HELP_TP branch. Its close but needs some bookkeeping to make it robust. I managed after some effort to get HELD working I did this in C++ so I will try to port to julia, which shouldn't take long. I will try to contact NLSolvers, what we need is well documented but is somewhat bespoke due the the 1-sum(xi) used on the nc component.

[pw0908]

I'd imagine that this constraint could be handled by a Lagrangian multiplier? Although implementing that might be easier said than done.

[ianhbell]

@branch171 - I'm also in C++, is your code somewhere publicly accessible? teqp is also written in C++, so I am very interested.