mbsim-env / fmatvec Goto Github PK

I'm using a symmatric matrix to perform a rotation of a 6x6 stiffness matrix like this:

SqrMat3 rotateY = BasicRotAIKy(phi);
SymMat randomRotationMatrix (6,EYE);
for (unsigned ri=0;ri<=2;ri++){
	for (unsigned rj=0;rj<=i;rj++){
		randomRotationMatrix(ri,rj) = rotateY(ri,rj);
		randomRotationMatrix(ri+3,rj+3) = rotateY(ri,rj);
		}
	}

SymMat rotatedStiffness(6,INIT,0.0);
rotatedStiffness = trans(randomRotationMatrix) * stiffnessMatrix * randomRotationMatrix;

This is a rather old code of mine: I've been using it this way for three years now, but when I compile against fmatvec commit 3c41097 I get the following error:

/usr/local/include/fmatvec/linear_algebra.h:1391:78: error: ‘const class fmatvec::Matrix<fmatvec::Symmetric, fmatvec::Ref, fmatvec::Ref, double>’ has no member named ‘T’
 1391 |   Matrix<Type,Col,Row,AT> trans(const Matrix<Type,Row,Col,AT> &A) { return A.T(); }
      |                                                                            ~~^

Is this a bug or the transpose of symmetric matrices is not currently supported?

Trying to get #5 done, I spotted an interesting, not trivial compile(er) error. Only MSVC (in all versions) complains about this, gcc and clang have no problem.

Problem:
linear_algebra_double.cc(782) and linear_algebra_double.cc(891) raise error C3066. The called function operator()(const Range<Var,Var> &I) const is declared both in class Vector<Ref,AT> and
Matrix<General,Ref,Ref,AT> (with different return types). Vector derived from Matrix. Both functions are not virtual. The root cause is the using Matrix<General, Ref, Ref, AT>::operator(); in vector.h, which pulls function name operator() into Vector. MSVC now complains about multiple possible ways that an object of this type can be called with these arguments... I am not convinced, that this is really a bug in MSVC. Anyway, this should be fixed (for MSVC or in general)

Potential Fix:

#ifdef _MSC_VER
	  AT* operator()() { return Matrix<General, Ref, Ref, AT>::operator()(); }
	  const AT* operator()() const { return Matrix<General, Ref, Ref, AT>::operator()(); }
#else
	  using Matrix<General, Ref, Ref, AT>::operator();
#endif

Here is a reproducer that can be used to play around e.g. with godbolt or whatever platofrm

template <class Type, class Row, class Col, class XT>
class TestA {};

template <class XT>
class TestA<float, float, float, XT>
{
public:
  float operator()(const int &I) const { return 1.0f; }
};

template <class XT>
class TestB : public TestA<float, float, float, XT>
{
public:
  double operator()(const int &I) const { return 1.0; }
  using TestA<float, float, float, XT>::operator();
};

void failMSVC(int num) {
	TestB<double> b;
	b(2);
}

I have seen the cmake branch here, which started in 2015 and which is based on cmake 2.x (as far as I have seen). With this issue, I want to push for a sound, maintained cmake build.

I would like to see (and implement) the following:

• cmake build using cmake >= 3.10 (e.g. using target_include_directories instead of include_directories)
• drop in replacement for current autoconf/configure process, remove dependencies to autoconf intermediate artifacts (config.h.in-cmake)
• setup cmake build process to be platform neutral (allow for future MSVC build)
• beside make, ninja should be a supported generator

Remarks:

• Centos 7 ships with cmake 2.8, and installing cmake 3.x via RPM caused me some headache; but setting up cmake from source code works perfectly (in my docker image) - so this should not be an issue.
• FIND_PACKAGE(LAPACK) was not working, if LAPACK had been installed from source using configure/make/make install. It turned out to be a problem of case -> FIND_PACKAGE(lapack) works.

I see two use cases for docker images within fmatvec project:

1. Continuous integration
2. Very concise, declarative way to describe prerequisites for building the software.

I admit, that I do not have enough insights into the current build process to decide, whether docker makes sense (or if it is even already in use).
But imho, it would definitely lower the bar for new users/contributors. Even if not using docker itself, the Dockerfile can be used as blueprint on how to setup a working build environment.
I have prepared two files at the moment, one targets debian:buster, the other target centos7.

If you think docker images make sense, I can share the Dockerfiles I have already created in my private fork of this project.

fmatvec does not compile without installing boost before.
This is not tracked by the configure script.

Implement a memory alignment for the fmatvec builtin allocator to be able to 
use Intel MKL efficiently.

Original issue reported on code.google.com by [email protected] on 9 Nov 2011 at 9:38

Based on preparation made in isse #4 , the library shall be usable on Windows using MSVC toolchain. Target would be MSVC++ 14.1 _MSC_VER == 1910 (Visual Studio 2017 version 15.0; support for Visual Studio < 2015 would require more refactorintg, see this Microsoft document.

Todos:

• fix compile errors (not that many)
• align compiler settings
• extend cmake script to support MSVC
• if using dll, all static variables have to be checked thoroughly for portability

Remarks:

• Linux build creates a shared library (so), the equivalent for Windows would be a dll;
  • Because of the extensive use of templates, the dll might be anemic
  • Because of Microsoft's weird name mangling, a linker lib would be part of the package in addition to dll and headers
  • Maybe it would simplify the usage, if just a static lib + header would make the interface?
  • a static lib would avoid the need for any means (likely a macro) to inject " __declspec(dllexport)" for functions exported by the Windows dll.

=> issue to be discussed!