Optimizing the source term added to the momentum equation

[uttamcadambi07]

Hi,

You mentioned that there is no support for fvOptions.

I wanted to know how straightforward would it be to optimize a source term added to the momentum equation (in DASimpleFoam solver for example) to reduce a pre-defined objective function (from say DAObjFunc) and what would be a good place for me to start looking.

[friedenhe]

You can use fvOptions to add source terms in DAFoam. But we did not test if the adjoint accuracy was good...

[uttamcadambi07]

But would I be able to update this source term based on an objective function? Just like teh same way I update beta field for field inversion

[friedenhe]

No, you won't. If you want to do that, you need to implement some new funcs. Refer to the DAFoam workshop 2022 on "How to add new design variables".

[uttamcadambi07]

Hi, I beleive source term as a design variable is implemented now in DAFoam?

[friedenhe]

Yes, you can use fvSource as the design variable. Check this script: https://github.com/mdolab/dafoam/blob/main/tests/runTests_DASimpleFoamkOmegaSSTFieldInversion.py

[uttamcadambi07]

But I see that this is implemented as a boundary condition? Can it be used in the same as way beta (like adding a spatially varying term to momentum equation and we optimise this the same way we optimise beta)?

[uttamcadambi07]

To be more specific, the designVarType of fvSource is now BC. But can it be extended to designVarType Field?

[friedenhe]

Yes. Check:

dafoam/tests/runTests_MphysAeroProp.py

Line 84 in 273a80b

"fvSource": {"designVarType": "Field", "fieldName": "fvSource", "fieldType": "vector"},

[uttamcadambi07]

Hi, so I have been trying to do this but I am not successful. Perhaps there are a lot of questions that I have which I am not able to find answers to. For this reason, I post them here.
dafoam version: 3.0.6
test case: periodic hill
task: optimizing momemtum source (fvSource) to minimize objective function
runScript: runScript.zip
Here is my configure function

    def configure(self):
        # configure and setup perform a similar function, i.e., initialize the optimization.
        # But configure will be run after setup

        # add the objective function to the cruise scenario
        self.cruise.aero_post.mphys_add_funcs()

        # define an angle of attack function to change the U direction at the far field
        def fvSource(val, DASolver):
            for idxI, v in enumerate(val):
                cellI = idxI%3
                DASolver.setFieldValue4LocalCellI(b"fvSource", v, idxI, cellI)
                                
        self.cruise.coupling.solver.add_dv_func("fvSource", fvSource)
        self.cruise.aero_post.add_dv_func("fvSource", fvSource)

        
        # add the design variables to the dvs component's output
        self.dvs.add_output("fvSource", val=np.array([0] * nCells*3))
        self.connect("fvSource", "cruise.fvSource")

        # define the design variables to the top level
        self.add_design_var("fvSource", lower=-1e-03, upper=1e-3, scaler=1.0)

        # add objective and constraints to the top level
        self.add_objective("cruise.aero_post.FI", scaler=1.0)

The reason i use fieldInversion in my objective function type is that I want to re-use the objective function without having to re-implement. I use SpalartAllMarasFv3FieldInversion because only then can I get the UData file in the object registry. I disable beta as the design variable so that it does not get optimized.

Please offer your valuable suggestions:

1. If I want to optimize a momentum source term for the periodic hill case, how do i separate the fvSource term added to maintain constant bulk velocity and the fvSource term that I wish to optimize? I do not know how to make this distinction.
2. How do i write a function to assign values to the fvSource term, just as how I do it for the betaFieldInversion term?

I did set this case up and try to run but then I am getting adjoint solution failed.

[friedenhe]

1. You won't be able to separate them in the current DAFoam version. A quick workaround is to hard code the pressure gradient term to the momentum equation using a different variable name, e.g., dp.
2. Yes, you can write a function similar to betaFieldInversion to assign values to fvSource.

[uttamcadambi07]

Okay so a few updates on this.

My hard coded source term is not working as expected. I added the following to DASimpleFoam.C file under solvePrimal() function

/*
User defined section starts here
*/
   /*Info <<"Check what value of body force should be added "<<endl;

    scalar dp_val = daOptionPtr_->getOption<scalar>("dp_val");

    Info << "Value of body force to be added is " << dp_val << endl;


    volVectorField dp
        (
                IOobject
                (
                "dp",                    // This is label asigned to the object in the register.
                runTime.timeName(),     // This is the place where the object will be saved 
                mesh,                   // This is the object which will act as register.
                IOobject::NO_READ,      // Reading options (in case it founds a file named "B" do not read it")
                IOobject::AUTO_WRITE    // Writing options
                ),
        mesh,
        dimensionedVector("dp", dimensionSet(0,1,-2,0,0,0,0), Foam::vector(dp_val, 0.0, 0.0))  // This is used to "size" the field to mesh domain.
        ); 
    */ 

/*
User defined section ends here
*/

This essentially reads dp_val from daOptions in the runScript.py and sets it here. I have a default value of 0 which is defined in pyDAFoam.py. I also add this to my UEqn.H file

tmp<fvVectorMatrix> tUEqn(
    fvm::div(phi, U, divUScheme)
    + fvm::Sp(alphaPorosity, U)
    + MRF.DDt(U)
    + turbulencePtr_->divDevReff(U)
    - fvSource
    //- dp
    - fvOptions(U));
fvVectorMatrix& UEqn = tUEqn.ref();

(it has all been commented out for now).

So with this, I should be able to add the source term dp_val of 6.63E-06 as per the tutorial and get the same effect as adding uniform pressure gradient source term through fvSource right? But turns out that my adjoint solver for the baseline design does not converge and the preliminary or baseline result does not look like the result from the fieldInversion case. When I comment out this part, it all works fine.

Q1. What is the mistake here?

Secondly, I decided to leave this and focus on problems that do not require a body force term to be added, hence freeing up fvSource to be used as a design variable. I do so for the case of the NACA0012 airfoil at 16 degree angle of attack. I run a case with LaunderSharmaKE and use that as my reference. To avoid coding a new objective function, I use the fieldInversion objective function formulation without including beta as the design variable. The case details:
Airfoil: NACA0012
AoA: 16 degree
Re: 10250
Baseline: SA
Reference: kEpsilon

Q2. This is allowed right? basically the reasons for doing this are two fold - to not write a new objective function and to not go into the complication of reading the UData file.

To test a preliminary run for this case, I do a simple field inversion using the Spalart-Allmaras turbulence model and result from kEpsilon as my reference. The case proceeds very well, here is the output log of the simulation

List of user-set options:

                                    Name   Value                used
                             alpha_for_y = full                  yes
                         constr_viol_tol = 1e-05                 yes
                        file_print_level = 5                     yes
                   hessian_approximation = limited-memory        yes
              limited_memory_max_history = 10                    yes
                           linear_solver = mumps                 yes
                                max_iter = 100                   yes
                             mu_strategy = adaptive              yes
                      nlp_scaling_method = none                  yes
                             output_file = opt_IPOPT.txt         yes
                             print_level = 5                     yes
                      print_user_options = yes                   yes
                                recalc_y = yes                   yes
                                      sb = yes                   yes
                                     tol = 1e-05                 yes
This is Ipopt version 3.13.5, running with linear solver mumps.
NOTE: Other linear solvers might be more efficient (see Ipopt documentation).

Number of nonzeros in equality constraint Jacobian...:        0
Number of nonzeros in inequality constraint Jacobian.:     9324
Number of nonzeros in Lagrangian Hessian.............:        0

Total number of variables............................:     9324
                     variables with only lower bounds:        0
                variables with lower and upper bounds:     9324
                     variables with only upper bounds:        0
Total number of equality constraints.................:        0
Total number of inequality constraints...............:        1
        inequality constraints with only lower bounds:        0
   inequality constraints with lower and upper bounds:        0
        inequality constraints with only upper bounds:        0

iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
   0  3.4058521e+01 0.00e+00 5.60e-01   0.0 0.00e+00    -  0.00e+00 0.00e+00   0
   1  3.4058564e+01 0.00e+00 7.65e-01  -0.3 4.61e-01    -  9.98e-01 1.00e+00f  1
   2  9.1386016e+00 0.00e+00 5.40e-01  -0.4 8.68e-01    -  1.00e+00 1.00e+00f  1
   3  6.6891599e+00 0.00e+00 4.50e-01  -6.4 1.75e+00    -  7.95e-01 1.00e+00F  1
   4  6.6890295e+00 0.00e+00 3.74e-01  -7.1 7.78e-01    -  8.82e-01 1.00e+00f  1

Now, I switch to fvSource as the design variable. Attaching the
sample_run.zip file for you here.

Now I am starting to face issues. My objective function is not reducing at all and the dual infeasibility is high (presumably because of the scaling of the design variable). Here is the log file so far:

List of user-set options:

                                    Name   Value                used
                             alpha_for_y = full                  yes
                         constr_viol_tol = 1e-05                 yes
                        file_print_level = 5                     yes
                   hessian_approximation = limited-memory        yes
              limited_memory_max_history = 26                    yes
                           linear_solver = mumps                 yes
                                max_iter = 100                   yes
                             mu_strategy = adaptive              yes
                      nlp_scaling_method = gradient-based        yes
                             output_file = opt_IPOPT.txt         yes
                             print_level = 6                     yes
                      print_user_options = yes                   yes
                                recalc_y = yes                   yes
                                      sb = yes                   yes
                                     tol = 1e-05                 yes
This is Ipopt version 3.13.5, running with linear solver mumps.
NOTE: Other linear solvers might be more efficient (see Ipopt documentation).

Number of nonzeros in equality constraint Jacobian...:        0
Number of nonzeros in inequality constraint Jacobian.:    27972
Number of nonzeros in Lagrangian Hessian.............:        0

Total number of variables............................:    27972
                     variables with only lower bounds:        0
                variables with lower and upper bounds:    27972
                     variables with only upper bounds:        0
Total number of equality constraints.................:        0
Total number of inequality constraints...............:        1
        inequality constraints with only lower bounds:        0
   inequality constraints with lower and upper bounds:        0
        inequality constraints with only upper bounds:        0

iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
   0  3.4058521e+01 0.00e+00 1.12e+01   0.0 0.00e+00    -  0.00e+00 0.00e+00   0
   1  3.4059495e+01 0.00e+00 5.25e+01  -4.0 1.10e+01    -  8.92e-01 8.92e-01S1076
   2  3.4059359e+01 0.00e+00 2.44e+01   0.9 5.26e+01    -  1.00e+00 6.10e-05f 15
   3  3.4059353e+01 0.00e+00 5.78e+01   0.2 9.59e-04    -  1.00e+00 5.00e-01f  2
   4  3.4059342e+01 0.00e+00 1.31e+01   0.2 2.81e-03    -  1.00e+00 2.50e-01f  3
   5  3.4059330e+01 0.00e+00 5.52e+01  -0.5 1.19e-02    -  1.00e+00 2.50e-01f  3
   6  3.4059317e+01 0.00e+00 4.17e+01  -0.5 1.50e-02    -  1.00e+00 1.25e-01f  4
   7  3.4059296e+01 0.00e+00 5.22e+01  -0.5 1.28e-01    -  1.00e+00 6.25e-02f  5
   8  3.4059276e+01 0.00e+00 9.16e+01  -0.5 1.39e-01    -  1.00e+00 6.25e-02f  5
   9  3.4059250e+01 0.00e+00 7.74e+01  -0.5 1.99e-01    -  1.00e+00 6.25e-02f  5
iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
  10  3.4059223e+01 0.00e+00 8.35e+01  -0.5 3.20e-01    -  1.00e+00 1.56e-02f  7
  11  3.4059210e+01 0.00e+00 2.82e+01  -0.5 1.07e-02    -  1.00e+00 1.25e-01f  4
  12  3.4059195e+01 0.00e+00 5.64e+01  -0.5 5.18e-02    -  1.00e+00 6.25e-02f  5

Q3. Is there some error in the way I have set up the problem?

Bascially I would like to use fvSource as a design variable and the objective function in DAObjFuncFieldInversion.C and optimize fvSource to get the SA model prediction to match the kEpsilon model result. Your input on this matter will be very useful and I can share any other information if required.

[friedenhe]

Q1. The way you added fvSource looks OK. Note that you also need to add the dp in the DAResidualSimpleFoam.C
Q2. Yes
Q3. Did the flow and adjoint converge well for this setup? Also, the way you formulate the problem is not quite right. The reference (kEpsilon) model has no fvSource term in the momentum equation. But in the field inversion, you tried to change the fvSource in the momentum equation to match the reference data. I suggest you add the fvSource term to the SA model's governing equation, instead of adding fvSource to the momentum equation.

[uttamcadambi07]

Q1. The way you added fvSource looks OK. Note that you also need to add the dp in the DAResidualSimpleFoam.C
Thanks for the tip, I will add it and keep you posted.

Q2. Did the flow and adjoint converge well for this setup?
Yes the flow and adjoint are converging well for me.

Also, the way you formulate the problem is not quite right. The reference (kEpsilon) model has no fvSource term in the momentum equation. But in the field inversion, you tried to change the fvSource in the momentum equation to match the reference data. I suggest you add the fvSource term to the SA model's governing equation, instead of adding fvSource to the momentum equation.

So this is just a sample case to test the working of the concept of adding a momentum source term to perform data assimilation. Our end goal is to use a different data set (presumably DNS of a flow past an airfoil or even LES) to match the SA model to that by optimizing the added momentum source term. Do you think I will have better success if I just use the high fidelity data instead of trying with two turbulence models? My thinking was that since the physics captured by a one equation and two equation models are sufficiently different ( as evidenced by the objective function) I was under the impression that using a momentum source might allow the reconciliation of the two models without having to change the model formulation.

[friedenhe]

I suggest you first verify the adjoint derivatives, df/dfvSource, with finite-difference refs. You may also play with the scaler for the fvSource design variables. For beta, its values are around one, so we use scaler=1. But for fvSource, its values can be much smaller/larger than one, so you need to set it such that scaler*fvSource ~=1. Another thing you may want to change is to use SNOPT or play with the IPOPT optimization parameters. Hope it helps.

[uttamcadambi07]

Hi, I am back with this issue again.

So i fixed the bug for writing out sensitivities (#506 (comment)) which means using the v2 script and dafoam v3.0.6, I can write out sensitivities by activating the writeSensMap command. Well and good.

Now my test case is as follows:
NACA0012
AoA: 16 degrees
Re: 10,000
Reference data: kEpislon turbulence model.

Baseline model: Spalart-Allmaras

Goal: optimize the fvSource variable in the momentum equation using a Spalart-Allmaras turbulence model by minimizing the objective function calculated as the difference of velocities between the kEpsilon turbulence model and Spalart-Allmaras turbulence model.

Mesh generated using: pyHyp. Mesh has been rotated to ensure that the incoming flow is horizontal.

BCs: inletOutlet for the circumference (switches between a fixed value and zeroGradient), noSlip wall.
y+ = min = 0.32, max = 4.71, average: 1.71 so no wall function is used.

I use upwind discretisation and set these values for the adjoint

"adjEqnOption": {"gmresRelTol": 1.0e-8, "pcFillLevel": 2, "jacMatReOrdering": "natural", "gmresMaxIters": 3000},

But somehow my design variable is not being updated at all. I am attaching first the log file

List of user-set options:

                                    Name   Value                used
                          acceptable_tol = 1e-07                 yes
                             alpha_for_y = full                  yes
                         constr_viol_tol = 1e-07                 yes
                        file_print_level = 5                     yes
                   hessian_approximation = limited-memory        yes
              limited_memory_max_history = 26                    yes
                           linear_solver = mumps                 yes
                                max_iter = 20                    yes
                             mu_strategy = adaptive              yes
                      nlp_scaling_method = gradient-based        yes
                             output_file = opt_IPOPT.out         yes
                             print_level = 6                     yes
                      print_user_options = yes                   yes
                                recalc_y = yes                   yes
                                      sb = yes                   yes
                                     tol = 1e-07                 yes
This is Ipopt version 3.13.5, running with linear solver mumps.
NOTE: Other linear solvers might be more efficient (see Ipopt documentation).

Number of nonzeros in equality constraint Jacobian...:        0
Number of nonzeros in inequality constraint Jacobian.:    27972
Number of nonzeros in Lagrangian Hessian.............:        0

Total number of variables............................:    27972
                     variables with only lower bounds:        0
                variables with lower and upper bounds:    27972
                     variables with only upper bounds:        0
Total number of equality constraints.................:        0
Total number of inequality constraints...............:        1
        inequality constraints with only lower bounds:        0
   inequality constraints with lower and upper bounds:        0
        inequality constraints with only upper bounds:        0

iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
   0  3.9872904e+03 0.00e+00 8.34e-06   0.0 0.00e+00    -  0.00e+00 0.00e+00   0
   1  3.9872904e+03 0.00e+00 3.11e+02  -6.3 1.67e-06    -  9.90e-01 1.00e+00f  1
   2  3.9872904e+03 0.00e+00 3.10e+02  -2.4 1.65e-06    -  1.00e+00 1.00e+00f  1
   3  3.9872904e+03 0.00e+00 3.12e+02  -2.4 5.33e+01    -  9.34e-03 7.29e-05f  8
   4  3.9872904e+03 0.00e+00 7.63e+01  -1.0 5.31e+01    -  9.24e-03 9.24e-03S1069
   5  3.9872904e+03 0.00e+00 1.30e+02  -2.4 4.23e+02    -  1.18e-03 1.84e-05f  7
   6  3.9872904e+03 0.00e+00 3.19e+02  -2.4 5.21e+00    -  2.35e-01 5.80e-08f 15
   7  3.9872904e+03 0.00e+00 3.59e+02  -2.4 5.15e-02    -  1.00e+00 3.90e-05f 13
   8  3.9872904e+03 0.00e+00 5.99e+02  -2.4 4.79e-03    -  1.00e+00 2.44e-04f 13
   9  3.9872904e+03 0.00e+00 4.12e+02  -2.4 5.02e-03    -  1.00e+00 2.44e-04f 13
iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
  10  3.9872904e+03 0.00e+00 1.10e+02  -2.4 1.55e-02    -  1.00e+00 1.62e-04f 13
  11  3.9872904e+03 0.00e+00 2.76e+02  -2.4 2.16e-03    -  1.00e+00 3.05e-05f 16
  12  3.9872904e+03 0.00e+00 2.52e+02  -2.4 4.74e-03    -  1.00e+00 1.98e-323h1073
  13  3.9872904e+03 0.00e+00 7.64e+01  -2.4 4.93e-03    -  1.00e+00 1.98e-323h1073
  14  3.9872904e+03 0.00e+00 2.26e+02  -2.4 7.40e+01    -  4.50e-03 1.91e-04f  6
  15  3.9872904e+03 0.00e+00 6.05e+02  -2.4 1.89e+00    -  5.28e-01 2.32e-01w  1
  16  3.9872904e+03 0.00e+00 4.22e+02  -2.4 2.38e+00    -  3.14e-01 7.47e-04w  1
  17  3.9872904e+03 0.00e+00 1.73e+03  -2.4 9.47e-03    -  1.00e+00 1.00e+00w  1
  18  3.9872904e+03 0.00e+00 1.54e+03  -2.4 5.93e-03    -  5.28e-01 1.13e-04f 11
  19  3.9872904e+03 0.00e+00 2.13e+02  -2.4 4.21e-02    -  1.00e+00 4.88e-04f 12
iter    objective    inf_pr   inf_du lg(mu)  ||d||  lg(rg) alpha_du alpha_pr  ls
  20  3.9872904e+03 0.00e+00 7.62e+01  -2.4 1.60e-03    -  1.00e+00 9.77e-04f 11

Number of Iterations....: 20

                                   (scaled)                 (unscaled)
Objective...............:   3.9872904328855993e+03    3.9872904328855993e+03
Dual infeasibility......:   7.6234497202807106e+01    7.6234497202807106e+01
Constraint violation....:   0.0000000000000000e+00    0.0000000000000000e+00
Complementarity.........:   8.6026888613558762e-03    8.6026888613558762e-03
Overall NLP error.......:   7.6234497202807106e+01    7.6234497202807106e+01


Number of objective function evaluations             = 3416
Number of objective gradient evaluations             = 21
Number of equality constraint evaluations            = 0
Number of inequality constraint evaluations          = 3416
Number of equality constraint Jacobian evaluations   = 0
Number of inequality constraint Jacobian evaluations = 21
Number of Lagrangian Hessian evaluations             = 0
Total CPU secs in IPOPT (w/o function evaluations)   =    116.704
Total CPU secs in NLP function evaluations           =   3133.168

EXIT: Maximum Number of Iterations Exceeded.

followed by the sensitivity

My question is: how is the implementation of fvSource as a design variable? I tried searching for the source code but I am not clear. Are you sure it is done for the entire field?

My second question is: can I use the alphaPorosity as an implicit source and just optimize that design variable? It is implemented as fvm::Sp(alphaPorosity, U) in the momentum equation. So this just means that an implicit source S(alpha) = alpha*U is added to the momentum equation right? Kind of like what we want to do but not exactly I would say. What do you think?

[friedenhe]

Regarding your first Q, you can verify if fvSouce is updated as expected by manually setting a non-zero fvSource initial field in runScript.py. Regarding your 2nd Q, yes, what you want is sort of a topology optimization. We have a DAFoam tutorial for that. One last thing, we found was that the IPOPT did not work for topology optimization, you have to use SNOPT instead. So the fvSource not changing issue may be caused by the IPOPT optimizer.

[uttamcadambi07]

Thanks Dr. He. These are massively helpful comments. Quick follow up question - how does the optimizer affect the accuracy the gradients? I presume the adjoint equation solution is independent of the choice of the optimizer right? So technically, my sensitivity should look reasonable but the design variable not updating could be attributed to the optimizer (in which case, the choice of SNOPT or IPOPT making a difference makes sense to me).

[friedenhe]

Yeah, the choice of the optimizer will not impact the gradient accuracy. I am not sure what caused the super large gradient values near the far field bc. Did the adjoint converge well?

[uttamcadambi07]

Yup the adjoint converged quite well. It is quite strange really. Because the gradients do not look okay, I am a little anxious to purchase SNOPT and try it. If it was an optimizer problem, I would have gone ahead and done it confidently.

The adjoint converged down to 10 orders

of magnitude within 600 iterations. Maybe I can send the case to you to have a look? Here it is :

error.zip

[friedenhe]

Can you use the finite-difference or forward-mode AD to check if the adjoint gradients are accurate? We know that the adjoint gradients may become inaccurate if there is flow separation. I suggest you try the upwind schemes in fvSchemes and see if it helps the adjoint convergence.

[uttamcadambi07]

Yes i will try using FD and forward mode AD. By the way, the adjoint convergence is never an issue. As I said before, the adjoint is converging properly.

Adjoint gradients may be inaccurate if there is flow separation? Have you tested it for highly separated flows? That sounds like bad news to us because we were looking to use DAFoam for separated flows. Have you quantified the inaccuracy?

[friedenhe]

The gradients MAY be inaccurate if there is a large flow separation. I suggest you verify the gradients before running an optimization. We managed to run many optimizations for separated flows without a problem. However, in some rare cases, the gradients become inaccurate. This issue should be caused by the bounding in the Gauss linearUpwindV grad(U) scheme (bounding creates discontinuity that adjoint does not like). This discontinuity does not necessarily create inaccurate gradients, but sometimes they can.

[uttamcadambi07]

@friedenhe i must say, this has single handedly been such a remarkable thread! I got my case to work by using the SNOPT optimiser for the fvSource!!! Indeed it was the IPOPT optimiser that was causing the problem. The assimilated solution that I get is SPOT ON. We are still in disbelief at how remarkably efficient your adjoint code is. I want to personally thank you for your support.
Now we just publish all this and take DAFoam to more people! (P.S in our research group we are already using it quite extensively. You should definitely think of having another webinar!!)

[friedenhe]

It is great to hear that SNOPT works. Please help us advertise DAFoam; hopefully, it will be helpful for others. Yes, we will have a seminar in 2024 summer.

[uttamcadambi07]

Hi, just wanted to check - did you get a chance to investigate why the fvSource optimisation does not work with IPOPT? I noticed that you have made some changes in the recent version of dafoam - do you think it is worth trying IPOPT with fvSource optimisation after making these changes?

The reason I’m asking is - the SNOPT pre compiled libraries do not work on our HPC system which is forcing us to buy the license. But just as we did in the case of personal workstation to try SNOPT we want to do the same on the cluster before we buy the license

[friedenhe]

Not yet... We are not using IPOPT as our main optimizer.

[lnhang0618]

Thanks for this discussion, it has been very helpful!