Remove ForwardDiff dependency

[klamike]

No description provided.

[klamike]

I think this is good to go now. You were right @samtalki, some of the switching terms were missing...

[samtalki]

paging @djturizo as he mentioned he has previously worked out closed form expresions of the implicit function theorem applied to AC OPF in some of his legacy code https://github.com/djturizo/Shortest-Path-OPF

[samtalki]

This is an incredibly valuable contribution that will be a core piece of many downstream applications, thank you @klamike . To summarize my (minor) comments overall:

• It would be helpful to deduplicate some of the repeated physics logic into consistent derivative primitives, and
• there are several places where we may be able to better exploit sparsity and avoid densifying matrices.

[klamike]

Thanks for the detailed comments @samtalki @cameronkhanpour, I will do some passes next week

[djturizo]

Left some comments

[github-actions]

Benchmark Results (Julia v1)

Time benchmarks

	main	dc7c79e...	main / dc7c79e...
ac_opf/kkt_jacobian/case30.m	0.138 ± 0.0055 s	3.57 ± 0.15 ms	38.7 ± 2.2
ac_opf/kkt_param/case30.m/switching	2.56 ± 1.3 ms	0.116 ± 0.009 ms	22.1 ± 11
dc_opf/kkt_jacobian/case30.m/cost_linear	0.15 ± 0.001 μs	0.151 ± 0.01 μs	0.993 ± 0.066
dc_opf/kkt_jacobian/case30.m/cost_quadratic	0.15 ± 0.011 μs	0.15 ± 0.011 μs	1 ± 0.1
dc_opf/kkt_jacobian/case30.m/demand	0.28 ± 0.03 μs	0.261 ± 0.041 μs	1.07 ± 0.2
dc_opf/kkt_jacobian/case30.m/flowlimit	0.4 ± 0.04 μs	0.391 ± 0.08 μs	1.02 ± 0.23
dc_opf/kkt_jacobian/case30.m/full	13.7 ± 8.2 μs	13.5 ± 5.2 μs	1.01 ± 0.72
dc_opf/kkt_jacobian/case30.m/susceptance	0.092 ± 0.0039 ms	0.0892 ± 0.0037 ms	1.03 ± 0.062
time_to_load	1.97 ± 0.022 s	1.82 ± 0.0039 s	1.08 ± 0.012

Memory benchmarks

	main	dc7c79e...	main / dc7c79e...
ac_opf/kkt_jacobian/case30.m	22.7 k allocs: 0.185 GB	0.0339 M allocs: 1.18 MB	161
ac_opf/kkt_param/case30.m/switching	1.5 k allocs: 9.08 MB	1.49 k allocs: 0.602 MB	15.1
dc_opf/kkt_jacobian/case30.m/cost_linear	6 allocs: 0.328 kB	6 allocs: 0.328 kB	1
dc_opf/kkt_jacobian/case30.m/cost_quadratic	6 allocs: 0.328 kB	6 allocs: 0.328 kB	1
dc_opf/kkt_jacobian/case30.m/demand	6 allocs: 1.42 kB	6 allocs: 1.42 kB	1
dc_opf/kkt_jacobian/case30.m/flowlimit	6 allocs: 1.89 kB	6 allocs: 1.89 kB	1
dc_opf/kkt_jacobian/case30.m/full	0.079 k allocs: 0.082 MB	0.079 k allocs: 0.082 MB	1
dc_opf/kkt_jacobian/case30.m/susceptance	2.28 k allocs: 0.292 MB	2.28 k allocs: 0.292 MB	1
time_to_load	0.149 k allocs: 11.1 kB	0.149 k allocs: 11.1 kB	1

[cameronkhanpour]

@klamike In the most recent commits I went ahead and addressed the comments @samtalki, @djturizo, and I made.
Please let me know if y'all are good with these changes.

I see that PR #48 is staged to merge the mk/backend branch into this mk/ac branch; do we want to wait until that PR is finished and merged before merging this branch into main?

[klamike]

Great work @cameronkhanpour!! Thank you for taking over and sorry for my delay, been super busy with moving to London. I reviewed the commit, the changes look good to me!

One thing I am curious about is the benchmark workflow. It would be great to verify (perhaps manually) that the final version does result in a speedup before merging (in particular on some medium-sized case e.g. 1354_pegase ACOPF).

Regarding the mk/backend branch, I think it would be great to merge eventually as I believe GPU support would be a killer feature, and it lays the groundwork for that. Feel free to take over that as well if you have the time/interest.

[cameronkhanpour]

I am not sure what is best practice, but I added a couple of new benchmarks for the AC OPF since the PR that added the benchmark workflow only had DC OPF. I did manually run case1354_pegase AC OPF and I verified some great speed ups:

Operation	mk/ac median	origin/main
Full AC KKT Jacobian	0.1043 s	Exceeded 20 minutes
Switching parameter Jacobian	0.0742 s	Exceeded 10 minutes

I got a little impatient and put in time limits so it wouldn't run forever on my PC, but safe to say that we get multiple orders of magnitude speed ups.

I can work on PR #48, taking a look at it briefly I think it might be best to merge this PR into main first then rebase PR 48 onto main since I can see there will be some conflicts that will need to be resolved.

[klamike]

Very nice! Agreed, let's merge this, then rebase. I initially set the target here since when I started working on that one, I based it off of here.

Comments resolved.

[samtalki]

Thank you so much @cameronkhanpour and @klamike !