# AC Optimal Power Flow in Various Nonlinear Optimization Frameworks

**URL:** <https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486>\
**Category:** Optimization (Mathematical)\
**Tags:** optimization, nonlinear\
**Created:** [March 25, 2022, 6:25pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486 "2022-03-25T18:25:05Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [April 4, 2022, 6:06am UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/23 "2022-04-04T06:06:28Z")

</div>

Is your code public?

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [April 4, 2022, 10:37am UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/24 "2022-04-04T10:37:09Z")

</div>

> [@djturizo](#):
>
> For the IEEE118 case is:
> 
> ```julia
> (MaxColor, Size) = (20, 236)
> 
> ```

Yeah that’s not enough for sparse diff. (That’s barely sparse 😅). Maybe the decompression could be optimized a bit more though.

---

<div class="post-metadata">

**Author:** ![djturizo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/djturizo/32/35005_2.png) [@djturizo](https://discourse.julialang.org/u/djturizo)\
**Post date:** [April 4, 2022, 6:12pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/25 "2022-04-04T18:12:30Z")

</div>

> [@ChrisRackauckas](#):
>
> > [@djturizo](#):
> >
> > For the IEEE118 case is:
> > 
> > ```julia
> > (MaxColor, Size) = (20, 236)
> > 
> > ```
> 
> Yeah that’s not enough for sparse diff. (That’s barely sparse 😅). Maybe the decompression could be optimized a bit more though.

What do you consider sparse? the number of structural non-zeros is roughly 3% for the IEEE118 case:

```julia
(NonZeros, Entries) = (1506, 55696)

```

And the percentage only goes down for larger cases. For the 2383 case we have:

```julia
(NonZeros, Entries) = (30636, 22714756)
(MaxColor, Size) = (20, 4766)

```

That’s roughly 0.15% of structural non-zeros. `SymbolicAD` seems to leverage this structure properly though.

> [@odow](#):
>
> Is your code public?

I just uploaded it to [Github](https://github.com/djturizo/power-flow-hessians). Just run `test.jl` and that’s it.  
EDIT: I forgot to mention that right now I’m only computing the PF Hessians and Jacobians. I will compute those terms for the constraints as well, but I haven’t implemented that yet.

---

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [April 4, 2022, 8:41pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/26 "2022-04-04T20:41:32Z")

</div>

Perhaps one other clarification. We’re only computing the jacobian and hessian of nonlinear (i.e., not linear or quadratic) constraints and objectives. We don’t compute it for linear or quadratic terms since they get handled by the solver.

---

<div class="post-metadata">

**Author:** ![djturizo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/djturizo/32/35005_2.png) [@djturizo](https://discourse.julialang.org/u/djturizo)\
**Post date:** [April 4, 2022, 10:00pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/27 "2022-04-04T22:00:31Z")

</div>

Does that include power flow constraints? they are general nonlinear in polar coordinates.

---

<div class="post-metadata">

**Author:** ![ccoffrin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ccoffrin/32/400_2.png) [@ccoffrin](https://discourse.julialang.org/u/ccoffrin)\
**Post date:** [April 4, 2022, 10:39pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/28 "2022-04-04T22:39:59Z")

</div>

Yes, what @odow is indicating is that these are the only equations that `SymbolicAD` is managing for building Jacobian and Hessian. The other parts of the AC-OPF problem are quadratic and have a different interface to the solver due to their simplified Jac/Hess structure.

---

<div class="post-metadata">

**Author:** ![ccoffrin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ccoffrin/32/400_2.png) [@ccoffrin](https://discourse.julialang.org/u/ccoffrin)\
**Post date:** [June 10, 2022, 3:13pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/29 "2022-06-10T15:13:36Z")

</div>

It has been a couple of months since I made this post and I am planning re-run these test with latest versions of all packages. Please let me know of any specific package improvements that you think could impact this analysis.

CC @ChrisRackauckas, @Vaibhavdixit02, @odow, @miles.lubin, @abelsiqueira, @mohamed82008, @pkofod

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 11, 2022, 2:44am UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/30 "2022-06-11T02:44:05Z")

</div>

The new Optimization.jl sparsity handling is probably worth a try.

[https://github.com/SciML/Optimization.jl/pull/265](https://github.com/SciML/Optimization.jl/pull/265)  
[https://github.com/SciML/Optimization.jl/pull/274](https://github.com/SciML/Optimization.jl/pull/274)

Additionally, if @YingboMa gets around to it then it might be interesting to try tearing

---

<div class="post-metadata">

**Author:** ![Vaibhavdixit02](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vaibhavdixit02/32/2916_2.png) [@Vaibhavdixit02](https://discourse.julialang.org/u/Vaibhavdixit02)\
**Post date:** [June 11, 2022, 7:36am UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/31 "2022-06-11T07:36:29Z")

</div>

I literally had a draft open with reply to your original post that we added sparsity support in Optimization.jl so you might want to give it a try 😄  
But we haven’t added documentation for it yet, the way to do it is pass `AutoModelingToolkit(true, true)` (the two fields are boolean for enabling sparsity for objective and constraint respectively).

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [June 11, 2022, 5:36pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/32 "2022-06-11T17:36:59Z")

</div>

I finished implementing sparsity and symbolic differentiation support in Nonconvex. Your rosetta-opf example works locally. I will make a release and update the docs shortly.

---

<div class="post-metadata">

**Author:** ![ccoffrin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ccoffrin/32/400_2.png) [@ccoffrin](https://discourse.julialang.org/u/ccoffrin)\
**Post date:** [June 12, 2022, 12:55am UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/33 "2022-06-12T00:55:05Z")

</div>

@mohamed82008, I tried with Nonconvex v1.0.3 but I am still getting this issue of zygote crashing, could you elaborate on how I should change these calls to use your symbolic diff approach?

```julia
model = Nonconvex.DictModel()
...
x0 = NonconvexCore.getinit(model)
r = Nonconvex.optimize(model, IpoptAlg(), x0)

```

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [June 12, 2022, 7:12am UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/34 "2022-06-12T07:12:00Z")

</div>

First you will need Nonconvex v1.0.4. Then you can do:

```julia
first_order = true
options = IpoptOptions(; first_order)
sp_model = sparsify(model, hessian = !first_order)
r = Nonconvex.optimize(sp_model, IpoptAlg(), x0; options)

```

`sparsify` will use Symbolics.jl to get the sparsity pattern of the gradients/Jacobians/Hessians and then use `SparseDiffTools` + `ForwardDiff` for the differentiation. Alternatively, you can use:

```julia
first_order = true
options = IpoptOptions(; first_order)
sym_model = symbolify(model, hessian = !first_order, sparse = true, simplify = true)
r = Nonconvex.optimize(sym_model, IpoptAlg(), x0; options)

```

which will use a `Symbolics`-only approach where the gradients/Jacobians/Hessians are obtained using Symbolics.jl. The `sparse` kwarg is used to tell Symbolics to return a sparse matrix/vector for the jacobian/Hessian/gradient.

Note that these are new features so please report any issues in the repo.

---

<div class="post-metadata">

**Author:** ![ccoffrin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ccoffrin/32/400_2.png) [@ccoffrin](https://discourse.julialang.org/u/ccoffrin)\
**Post date:** [June 19, 2022, 4:42pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/35 "2022-06-19T16:42:06Z")

</div>

As promised, below is a table of updated results using the latest versions of all packages. Note that GalacticOptim has been renamed [Optimization](https://github.com/SciML/Optimization.jl).

The substantive changes follow the discussion above. In particular, NonConvex and Optimization have been updated with new AD systems based on [Symbolics](https://github.com/JuliaSymbolics/Symbolics.jl) and now support sparse Jacobian and Hessian computations. For NonConvex, this allowed me to finish building the [NonConvex OPF model](https://github.com/lanl-ansi/rosetta-opf/blob/main/nonconvex.jl) and confirm that the model is correct on small networks. For Optimization, the new sparse AD system based on ModelingTookit enabled it to solve models with 73 network buses (800+ variables, 900+ constraints), which is a 2x scalability increase from what was possible with the previous dense ForwardDiff approach.

Great thanks to @mohamed82008 @Vaibhavdixit02 @odow for their help in debugging issues as we worked to update the rosetta-opf models.

For general awareness,

- This [Zygote issue](https://github.com/JuliaNonconvex/Nonconvex.jl/issues/130) has thus far blocked using Zygote for AD on these models
- These upstream issues [[1](https://github.com/SciML/RuntimeGeneratedFunctions.jl/issues/13)][[2](https://github.com/JuliaLang/julia/pull/45173)] appear to be the root cause blocking scaling of the ModelingTookKit approach to larger problems. It looks like it will be resolved in future Julia versions (testing was done on Julia v1.7.2).

| Case | Vars | Cons | JuMP | NLPModels | NonConvex | Optim | Optimization |
| --- | --- | --- | --- | --- | --- | --- | --- |
| case3\_lmbd | 24 | 28 | 1.22e-02 | 2.01e+01 | 6.19e+00 | N.D. | 1.77e+00 |
| case5\_pjm | 44 | 53 | 1.75e-02 | 1.51e-01 | 4.28e+00 | N.D. | 1.99e-01 |
| case14\_ieee | 118 | 169 | 6.54e-01 | 2.30e+01 | 8.77e+01 | INF. | 7.98e+00 |
| case24\_ieee\_rts | 266 | 315 | 5.38e-01 | 4.53e+01 | 5.61e+02 | N.D. | 2.14e+01 |
| case30\_ieee | 236 | 348 | 6.16e-01 | 3.65e+01 | 5.27e+02 | N.D. | 2.43e+01 |
| case30\_as | 236 | 348 | 6.05e-01 | 3.05e+01 | 4.88e+02 | N.D. | 2.25e+01 |
| case39\_epri | 282 | 401 | 6.95e-02 | 6.00e+01 | 4.40e+02 | N.D. | 2.95e+01 |
| case57\_ieee | 448 | 675 | 6.45e-01 | 1.05e+02 | 1.26e+03 | N.D. | 8.19e+01 |
| case60\_c | 518 | 737 | 6.41e-01 | 2.19e+02 | 2.51e+03 | N.D. | 1.06e+02 |
| case73\_ieee\_rts | 824 | 987 | 6.45e-01 | 5.97e+02 | 5.74e+03 | N.D. | 2.68e+02 |
| case89\_pegase | 1042 | 1649 | 9.08e-01 | 1.74e+03 | N.D. | N.D. | N.D. |
| case118\_ieee | 1088 | 1539 | 8.36e-01 | 1.74e+03 | N.D. | N.D. | N.D. |
| case162\_ieee\_dtc | 1484 | 2313 | 8.72e-01 | 4.26e+03 | N.D. | N.D. | N.D. |
| case179\_goc | 1468 | 2200 | 9.69e-01 | 7.06e+03 | N.D. | N.D. | N.D. |
| case200\_activ | 1456 | 2116 | 7.73e-01 | 2.80e+03 | N.D. | N.D. | N.D. |
| case240\_pserc | 2558 | 3617 | 3.09e+00 | N.D. | N.D. | N.D. | N.D. |
| case300\_ieee | 2382 | 3478 | 1.13e+00 | N.D. | N.D. | N.D. | N.D. |
| case500\_goc | 4254 | 6097 | 1.69e+00 | N.D. | N.D. | N.D. | N.D. |
| case588\_sdet | 4110 | 5979 | 1.55e+00 | N.D. | N.D. | N.D. | N.D. |
| case793\_goc | 5432 | 7978 | 2.01e+00 | N.D. | N.D. | N.D. | N.D. |
| case1354\_pegase | 11192 | 16646 | 6.82e+00 | N.D. | N.D. | N.D. | N.D. |
| case1888\_rte | 14480 | 21494 | 2.82e+01 | N.D. | N.D. | N.D. | N.D. |
| case1951\_rte | 15018 | 22075 | 1.16e+01 | N.D. | N.D. | N.D. | N.D. |
| case2000\_goc | 19008 | 29432 | 1.03e+01 | N.D. | N.D. | N.D. | N.D. |
| case2312\_goc | 17128 | 25716 | 8.91e+00 | N.D. | N.D. | N.D. | N.D. |
| case2383wp\_k | 17004 | 25039 | 9.37e+00 | N.D. | N.D. | N.D. | N.D. |
| case2736sp\_k | 19088 | 28356 | 7.67e+00 | N.D. | N.D. | N.D. | N.D. |
| case2737sop\_k | 18988 | 28358 | 8.01e+00 | N.D. | N.D. | N.D. | N.D. |
| case2742\_goc | 24540 | 38196 | 3.50e+01 | N.D. | N.D. | N.D. | N.D. |
| case2746wp\_k | 19520 | 28446 | 8.71e+00 | N.D. | N.D. | N.D. | N.D. |
| case2746wop\_k | 19582 | 28642 | 7.97e+00 | N.D. | N.D. | N.D. | N.D. |
| case2848\_rte | 21822 | 32129 | 1.76e+01 | N.D. | N.D. | N.D. | N.D. |
| case2853\_sdet | 23028 | 33154 | 1.26e+01 | N.D. | N.D. | N.D. | N.D. |
| case2868\_rte | 22090 | 32393 | 2.06e+01 | N.D. | N.D. | N.D. | N.D. |
| case2869\_pegase | 25086 | 37813 | 1.46e+01 | N.D. | N.D. | N.D. | N.D. |
| case3012wp\_k | 21082 | 31029 | 1.32e+01 | N.D. | N.D. | N.D. | N.D. |
| case3022\_goc | 23238 | 34990 | 1.38e+01 | N.D. | N.D. | N.D. | N.D. |
| case3120sp\_k | 21608 | 32092 | 1.26e+01 | N.D. | N.D. | N.D. | N.D. |
| case3375wp\_k | 24350 | 35876 | 1.47e+01 | N.D. | N.D. | N.D. | N.D. |
| case3970\_goc | 35270 | 54428 | 2.32e+01 | INF. | N.D. | N.D. | N.D. |
| case4020\_goc | 36696 | 56957 | 2.89e+01 | N.D. | N.D. | N.D. | N.D. |
| case4601\_goc | 38814 | 59596 | 2.84e+01 | N.D. | N.D. | N.D. | N.D. |
| case4619\_goc | 42532 | 66289 | 2.94e+01 | N.D. | N.D. | N.D. | N.D. |
| case4661\_sdet | 34758 | 51302 | 2.48e+01 | INF. | N.D. | N.D. | N.D. |
| case4837\_goc | 41398 | 64030 | 2.62e+01 | N.D. | N.D. | N.D. | N.D. |
| case4917\_goc | 37872 | 56917 | 2.78e+01 | N.D. | N.D. | N.D. | N.D. |
| case6468\_rte | 49734 | 75937 | 8.18e+01 | N.D. | N.D. | N.D. | N.D. |
| case6470\_rte | 50482 | 75976 | 4.56e+01 | N.D. | N.D. | N.D. | N.D. |
| case6495\_rte | 50426 | 76124 | 8.23e+01 | N.D. | N.D. | N.D. | N.D. |
| case6515\_rte | 50546 | 76290 | 6.09e+01 | N.D. | N.D. | N.D. | N.D. |
| case8387\_pegase | 78748 | 118702 | 6.51e+01 | N.D. | N.D. | N.D. | N.D. |
| case9241\_pegase | 85568 | 130826 | 6.62e+01 | N.D. | N.D. | N.D. | N.D. |
| case9591\_goc | 83572 | 130588 | 8.49e+01 | N.D. | N.D. | N.D. | N.D. |
| case10000\_goc | 76804 | 112352 | 5.75e+01 | N.D. | N.D. | N.D. | N.D. |
| case10480\_goc | 96750 | 150874 | 8.37e+01 | N.D. | N.D. | N.D. | N.D. |
| case13659\_pegase | 117370 | 170588 | 9.50e+01 | N.D. | N.D. | N.D. | N.D. |
| case19402\_goc | 179562 | 281733 | 1.93e+02 | N.D. | N.D. | N.D. | N.D. |
| case24464\_goc | 203374 | 313641 | 1.67e+02 | N.D. | N.D. | N.D. | N.D. |
| case30000\_goc | 208624 | 307752 | 3.54e+02 | N.D. | N.D. | N.D. | N.D. |

Package Details

[54578032] ADNLPModels v0.3.3  
[b6b21f68] Ipopt v1.0.2  
[4076af6c] JuMP v1.1.1  
[961ee093] ModelingToolkit v8.14.0  
[f4238b75] NLPModelsIpopt v0.9.1  
[01bcebdf] Nonconvex v2.0.3  
[bf347577] NonconvexIpopt v0.4.1  
[429524aa] Optim v1.7.0  
[7f7a1694] Optimization v3.6.1  
[fd9f6733] OptimizationMOI v0.1.1  
[c36e90e8] PowerModels v0.19.5

Ipopt was run with the default linear solver, MUMPS 5.4.1.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [June 19, 2022, 5:03pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/36 "2022-06-19T17:03:44Z")

</div>

> [@ccoffrin](#):
>
> These upstream issues [[1](https://github.com/SciML/RuntimeGeneratedFunctions.jl/issues/13)][[2](https://github.com/JuliaLang/julia/pull/45173)] appear to be the root cause blocking scaling of the ModelingTookKit approach to larger problems. It looks like it will be resolved in future Julia versions (testing was done on Julia v1.7.2).

Are you including the compilation time here? Yeah the RGF issues are one thing, and the other is we need to release SymbolicIR.

MTK also doesn’t do `structural_simplify` on OptimizationProblem right now, which can be a major win because then it solves a much smaller problem. @YingboMa was working on that.

---

<div class="post-metadata">

**Author:** ![ccoffrin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ccoffrin/32/400_2.png) [@ccoffrin](https://discourse.julialang.org/u/ccoffrin)\
**Post date:** [June 19, 2022, 5:33pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/37 "2022-06-19T17:33:11Z")

</div>

> [@ChrisRackauckas](#):
>
> Are you including the compilation time here?

Good question. In these runtime numbers I try to avoid capturing artifacts from one-time overheads, such as JIT time. In my experience, with sufficient effort, these can be avoided in production deployment settings.

In all of these implementations before I start collecting data `solve_opf("$(@ __DIR__ )/data/pglib_opf_case5_pjm.m")` is executed first, to compile the relevant code execution paths. Then `solve_opf(...)` is run again on the file where runtime data is being collected.

You can have a look at exactly how the data collection is done in [this script](https://github.com/lanl-ansi/rosetta-opf/blob/cli/rosetta-opf-cli.jl). It is not immediately obvious that pre-compilation is done there, but looking into the specific implementation files you will find it, for example, [https://github.com/lanl-ansi/rosetta-opf/blob/cli/optimization.jl#L376-L378](https://github.com/lanl-ansi/rosetta-opf/blob/cli/optimization.jl#L376-L378)

> [@ChrisRackauckas](#):
>
> MTK also doesn’t do `structural_simplify` on OptimizationProblem right now, which can be a major win because then it solves a much smaller problem. @YingboMa was working on that.

Cool, looking forward to seeing the next iteration.

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [June 19, 2022, 5:33pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/38 "2022-06-19T17:33:22Z")

</div>

Thanks for this excellent source of test cases for Nonconvex. For Nonconvex, I would be interested in the results using ReverseDiff as well as SparseDiffTools instead of Symbolics.

See [Using other AD packages · Nonconvex.jl](https://julianonconvex.github.io/Nonconvex.jl/stable/gradients/other_ad/) and [Sparse Jacobian or Hessian · Nonconvex.jl](https://julianonconvex.github.io/Nonconvex.jl/stable/gradients/sparse/) for the relevant docs sections.

---

<div class="post-metadata">

**Author:** ![ccoffrin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ccoffrin/32/400_2.png) [@ccoffrin](https://discourse.julialang.org/u/ccoffrin)\
**Post date:** [June 19, 2022, 5:56pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/39 "2022-06-19T17:56:14Z")

</div>

@mohamed82008, If you could show me how [these lines should be changed in nonconvex.jl](https://github.com/lanl-ansi/rosetta-opf/blob/main/nonconvex.jl#L229-L234) to test these approaches then I can do testing on some example network datasets.

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [June 19, 2022, 5:58pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/40 "2022-06-19T17:58:52Z")

</div>

> [@ccoffrin](#):
>
> these lines should be changed in nonconvex.jl

For SparseDiffTools, just drop the `symbolic = true`:

```julia
result = Nonconvex.optimize(
    model,
    IpoptAlg(),
    NonconvexCore.getinit(model);
    options = IpoptOptions(; first_order=false, sparse=true),
)

```

For ReverseDiff, you can do:

```julia
using AbstractDifferentiation, ReverseDiff

rd_model = abstractdiffy(model, AD.ReverseDiffBackend())
result = Nonconvex.optimize(
   rd_model,
   IpoptAlg(),
   NonconvexCore.getinit(model);
   options = IpoptOptions(; first_order=false),
)

```

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [June 19, 2022, 6:04pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/41 "2022-06-19T18:04:07Z")

</div>

> [@mohamed82008](#):
>
> `rd_model = abstractdiffy(model, ReverseDiffBackend())`

I don’t make use of tape compilation yet in Nonconvex but ReverseDiff is often quite fast already without compiling a tape for each function.

---

<div class="post-metadata">

**Author:** ![mohamed82008](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mohamed82008/32/18171_2.png) [@mohamed82008](https://discourse.julialang.org/u/mohamed82008)\
**Post date:** [June 19, 2022, 6:15pm UTC](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486/42 "2022-06-19T18:15:18Z")

</div>

Also how can I run all these problems for Nonconvex locally?

[Previous page](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486.md?page=1)

[Next page](https://discourse.julialang.org/t/ac-optimal-power-flow-in-various-nonlinear-optimization-frameworks/78486.md?page=3)