Modules + free form + fpm + cmake

[JorgeG94]

This PR will introduce breaking changes if the apps that use it are not updated accordingly!

A couple of things that still need to be done:

• update the readme to account for new way to build and link the library to other applications
• add tests!!
• confirm that my change for the .pow. is correct
• update the doc examples in Fortran

[JorgeG94]

@adtzlr can you just sanity check this for me? this used to be T2 and I think because of how interfaces were created it didn't die, but I see this as tensor^2 not Tensor2 based on the overloaded ** operator

[adtzlr]

Thanks @JorgeG94 for pointing that out! The original implementation gives the correct result, because the overloaded ** (double-dot) operator is for Tensor**Tensor operations only. So Tensor**Integer refers to the Matrix product, which is correct in this formula. No need for explicit .pow. here. I know, this can be confusing. Once you get the logic, it's very similar to hand-written matrix notation. I'd like to keep this behavior.

[JorgeG94]

I was having some issues with derived types since they are not going through explicit interfaces I believe, if I went back to ** it would not compile ! I will investigate this though.

[adtzlr]

Thanks @JorgeG94 for all the proposed changes. Please give me some time to go through all the changes (and I'll definitely come back with some questions...). It will take me some time ⏳ but your effort is very welcome 🚀! This was more or less the kind of contribution I was looking for because it is way out of my scope.

[JorgeG94]

Thanks @JorgeG94 for all the proposed changes. Please give me some time to go through all the changes (and I'll definitely come back with some questions...). It will take me some time ⏳ but your effort is very welcome 🚀! This was more or less the kind of contribution I was looking for because it is way out of my scope.

Thanks so much! I had quite a bit of fun doing this. Although this are breaking changes because of how the project can be included in other projects it is certainly the best way to go for the future. Modules + explicit interfaces are a great thing to have, they prevent many errors and bugs by doing checks at compile time.

Adding build systems that suit everyone's needs is also cool I am not sure how the commercial packages you mention are built inhouse, but surely this cannot hurt.

A potential cool thing to do would be to have a general way of handling tensors, I see that they are all set to be Cartesian i.e. Tensor1 is of size 3, etc.

[adtzlr]

A potential cool thing to do would be to have a general way of handling tensors, I see that they are all set to be Cartesian i.e. Tensor1 is of size 3, etc.

Definitely, like Tensor3D1 - but the 3d cartesian frame is more or less the use case of this module (stress/strain tensors of solid mechanics). I think this would add much more complexity (more functions in the interface blocks), errors for mixing Tensor3D and Tensor2D...