Vector integration in the DblPend example
Does anyone remember how our discussion back in #4247 concluded w.r.t. to this PR?
I admit to being confused with where we are at with this. I know we want to have double pendulum use vectors directly, rather than just focus on the components. @sarrasoussia made changes to the SRS to rewrite the theories in terms of vectors. It is my job to review this, but I'll have to track down which PR has this version when I get time to review. Maybe it is this one?
Hmm, maybe this PR is superseded by #4261?
https://github.com/JacquesCarette/Drasil/pull/4261/files#diff-538bbd015d7596d8b589b6a2553f2f629687b81debba60677e7dbad9a0f88638 (give it a minute to load, but it will bring you to stable/.../DblPend_SRS.html's diff)
I believe this is now ready for a review
It looks like this PR contains everything in #4261 ? Did you intend to target that PRs branch with this PR? It might be good to do that regardless, if only to review the changes unique to this PR solely within this PR.
Is there any way that we can keep code generation of DblPend working?
It looks like this PR contains everything in #4261 ? Did you intend to target that PRs branch with this PR? It might be good to do that regardless, if only to review the changes unique to this PR solely within this PR.
Is there any way that we can keep code generation of DblPend working?
I wanted to check if the equations in the SRS are correct first. With the current changes, code generation is still not available.
@sarrasoussia I've gone through your new version of the SRS. A marked-up pdf is attached. The main problem is with the derivations sections. You keep mentioning Clifford algebra, but Clifford algebra should not show up at all in the SRS. Clifford algebra is internal to Drasil. Externally, we want to generate documentation that looks like typical vector algebra. Your derivations should be much like the previous derivations, except written in vector form.
For the calculations (the generated code), I'm not sure really where Clifford algebra enters at all. Really, vector algebra isn't relevant in the generated code. The code is an ODE solver. The ODE can be represented as a system of equations in matrix form, but we don't do any operations on the system. (The current SRS version represents this as two separate scalar equations. We could change this to a vector representation if it is helpful, but I don't see that it adds anything right now.) The matrix representation is found by rearranging things as outlined in Dong's MEng report. Everything is then passed over to the external ODE solver library. We don't do any vector operations with these vectors for the calculations.
I haven't looked at the double pendulum code in a while. Maybe we can do vector operations for the output calculations? The position vector for mass 2 is calculated using the addition of the position vector for mass 1 plus some other terms. That would give us a place to exercise the vector addition code.
I re-targeted this PR to CSchankGA (i.e., #4261) rather than main so we can see the 'real' diff.
This PR introduces a substantially complete integration of GA into the dblpend example. The core language now supports a dedicated ClifS space type, multivector kinds, GA constructors, and key operations such as cScale, cAdd, negClif, vect, and the geometric/wedge products. In the dblpend example, all physical quantities (position, velocity, acceleration, force) are redefined as multivectors, with corresponding expressions implemented using the new GA operators. General definitions, data definitions, derivations, and instance models have been extended with detailed GA explanations, and the document body has been updated to display these definitions properly.
Currently fixing the merge conflicts