conservation law analysis

[isaacsas]

@kaandocal we're starting to think about adding some further network analysis. I know you used the SNF for the conservation laws in:

Catalyst.jl/src/networkapi.jl

Line 484 in 73d4f53

S, T, U = AbstractAlgebra.snf_with_transform(nsm_conv)

and your open PR.

Why did you choose SNF? Couldn't the conservation laws also be found using the nullspace functionality in AbstractAlgebra over the integers? (Note, I haven't dug too deeply into what AbstractAlgebra actually does under the hood here, I'm just trying to understand why SNF.) Thanks!

[isaacsas]

I also wonder if it might be more efficient to use the Nemo flint bindings? It seems like they wrap a lot of the Flint functionality but don't necessarily export it all.

https://github.com/Nemocas/Nemo.jl/blob/master/src/flint/fmpz_mat.jl

[kaandocal]

I chose SNF because I understand what it does! The code you cited just finds an integer for the left nullspace of the stoichiometry matrix (I believe the last release switched sides). I think AbstractAlgebra.nullspace uses some version of Gaussian Elimination so I think we could try using that. Will have to look into Nemo, never used it!

[isaacsas]

Yeah, sorry if we broke anything for you -- our basic stoichiometry matrices were backwards from the convention as I understand it in various literature (even Wikipedia has num reactions = num cols). It seemed better to break things now and get consistent with the literature rather than wait till even more users are potentially relying on it...

I think using the underlying Flint functionality, or the AbstractAlgebra nullspace/rank functionality gives us an avenue to (hopefully) better performance and allowing larger systems. Did you plan to update your PR on reducing systems per @YingboMa's comments? If you do it might be good to work in using more of the AbstractAlgebra functionality over the integers instead of the base rank and pinv functionality. Otherwise I might fork the PR at some point and try to address his comments myself.

[isaacsas]

Also, my understanding is that AbstractAlgebra was created to give Nemo a more general Julia-native backend that supports more types, but Nemo itself also has some optimized paths for certain specific types (like the Flint stuff for integer matrices). So Nemo is a much heavier dependency, but might offer some faster alternatives. (We'd need to benchmark...)

[kaandocal]

I caught the change pretty quickly, although it would probably be good to have a noticeable warning in the release notes ;) I will have a look at my PR, been quite busy recently - IIRC I ended up using more than just the nullspace in that one. I'm all for benchmarking!

[isaacsas]

Hmm, I just updated the readme yesterday to now point to a history file where we’ll log such stuff. How would you suggest communicating this more clearly? Like making it bold / distinguished in that file?

[kaandocal]

The history file is a good idea, I didn't check the Readme :) Since there have been several breaking releases this summer it might be worth underlining those in bold for the visually challenged like myself...

[isaacsas]

Yeah, I’ll do that.

[yewalenikhil65]

@isaacsas @kaandocal

This is LU factorization based nullspace calculation. And preserves "rational" eltype. Could this approach be helpful in this case?

https://github.com/rmsrosa/UnitfulBuckinghamPi.jl/blob/0f80578c4283648708e48fd592cc77fdc8c4c084/src/UnitfulBuckinghamPi.jl#L307

We could try doing similar with QR factorization. And then check how it fares against SNF?

[yewalenikhil65]

@isaacsas @kaandocal

This is LU factorization based nullspace calculation. And preserves "rational" eltype (I suspect it would give denominator as one always for all numbers for rational entries) . Could this approach be helpful in this case?

https://github.com/rmsrosa/UnitfulBuckinghamPi.jl/blob/0f80578c4283648708e48fd592cc77fdc8c4c084/src/UnitfulBuckinghamPi.jl#L307

We could try doing similar with QR factorization. And then check how it fares against SNF?

[isaacsas]

Does this have an advantage over the integer lu and null space versions in AbstractAlgebra?

[isaacsas]

One thing we need to be a little careful about is what space we are calculating the null space and such over, see Nemocas/AbstractAlgebra.jl#855

It sounds like we should perhaps be using Nemo for now.

[isaacsas]

Switched the backend for integer linear algebra to Nemo in #397

[isaacsas]

I think we've settled on using Nemo, so I'll close this.