Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: add linting #618

Merged
merged 13 commits into from
Feb 16, 2023
Merged

CI: add linting #618

merged 13 commits into from
Feb 16, 2023

Conversation

GPMueller
Copy link
Member

  • add C++ format linting and clang-tidy reporting for the core library
  • add C++ format linting and clang-tidy reporting for the ImGUI
  • add Python format and quality linting for the core library wrappers and tests
  • add Python format and quality linting for the ui-python folder

@codecov
Copy link

codecov bot commented May 1, 2022

Codecov Report

Merging #618 (24c4cc3) into develop (f19764f) will increase coverage by 0.31%.
The diff coverage is 54.94%.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #618      +/-   ##
===========================================
+ Coverage    48.16%   48.48%   +0.31%     
===========================================
  Files           74       75       +1     
  Lines        11968    12015      +47     
===========================================
+ Hits          5764     5825      +61     
+ Misses        6204     6190      -14     

@coveralls
Copy link

coveralls commented May 1, 2022

Coverage Status

Coverage: 80.833% (+0.1%) from 80.705% when pulling 24c4cc3 on feature-ci-linting into f19764f on develop.

@GPMueller GPMueller force-pushed the feature-ci-linting branch 3 times, most recently from e1553d7 to 8c25c98 Compare February 8, 2023 13:21
Should hopefully build with clang-15.

Needed to replace uses of `REQUIRE( ... == Approx( ... ) )` with `REQUIRE_THAT( ... WithinAbs( ... ) )`.
@GPMueller
Copy link
Member Author

GPMueller commented Feb 8, 2023

I've managed to fix the CI, except:

  • Depondt and SIB solvers don't achieve the expected precision when using OpenMP (the Depondt solver can be fixed with c982a34)
  • test_anisotropy.cpp contains a test comparing energies from Energy and Gradient_and_Energy, which only succeeds when the precision is lowered to 1e-4

@@ -1,38 +1,37 @@
#ifdef SPIRIT_USE_CUDA
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MSallermann can you take a closer look at this file, and maybe also execute tests using CUDA on this branch?

These changes are quite difficult to review and make sure they're OK just from looking at them...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's OK. I can build and run the Code with CUDA. Many of the unit tests fail though, because the requested precision is too high. I think it would be best to use different epsilons for double and single precision builds

This test trips up the Heun and SIB solvers when requiring higher
precision. This is an issue in their implementations and should really
be fixed.
@GPMueller GPMueller force-pushed the feature-ci-linting branch 2 times, most recently from 4a4413d to b8032d1 Compare February 11, 2023 13:22
@GPMueller GPMueller force-pushed the feature-ci-linting branch 21 times, most recently from ec306f7 to 4cba9a3 Compare February 11, 2023 22:50
 - update checkout action to v3, setup-python action to v4
 - add a Windows OpenMP build using LLVM
 - add an Ubuntu 22.04 CUDA build

On Ubuntu 22.04, we get gcc 11.3 and nvidia-cuda-toolkit 11.5, which are
not compatible, producing compilation errors. Therefore, a downgrade of
gcc to version 10 is needed.

Note: had to change `ChooseCompiler.cmake` to enable user-chosen
compilers via `USER_COMPILER_CXX` etc.
@GPMueller
Copy link
Member Author

@MSallermann I believe this PR is now ready

@MSallermann
Copy link
Member

MSallermann commented Feb 15, 2023

I've managed to fix the CI, except:

* Depondt and SIB solvers don't achieve the expected precision when using OpenMP (the Depondt solver can be fixed with [](https://github.com/spirit-code/spirit/commit/c982a34c604aa763bb615123be6fb442738a089c)

* `test_anisotropy.cpp` contains a test comparing energies from `Energy` and `Gradient_and_Energy`, which only succeeds when the precision is lowered to `1e-4`
  • I have pushed another commit to the suzuki_trotter branch 04e6b89. With this, and the commit you mentioned, I can set epsilon for the Larmor precession test to 1e-9 (as opposed to 1e-6 at the moment) and all solvers pass.
  • The problem with the last assert in test_anisotropy is that a float and a double are compared and the float truncates the last digits

REQUIRE( Approx( normal[0] ) == 0 );
REQUIRE( Approx( normal[1] ) == 0 );
REQUIRE( Approx( normal[2] ) == 1 );
REQUIRE_THAT( magnitude, WithinAbs( init_magnitude, 1e-12 ) );
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to set the 1e-12 epsilon value dependent on the precision, otherwise tests will fail when using single precision (float)

int N = 10000;
int N_check = std::min( 100, N );
vectorfield v1( N, Vector3{ 0.0, 0.0, 1.0 } );
vectorfield v2( N, Vector3{ 1.0, 1.0, 1.0 } );

REQUIRE( Engine::Vectormath::dot( v1, v2 ) == Approx( N ) );
REQUIRE_THAT( Engine::Vectormath::dot( v1, v2 ), WithinAbs( N, 1e-12 ) );
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to set the 1e-12 epsilon value dependent on the precision, otherwise tests will fail when using single precision (float)

REQUIRE( m[0] == Approx( 0 ) );
REQUIRE( m[1] == Approx( 0 ) );
REQUIRE( m[2] == Approx( mu_s ) );
REQUIRE_THAT( m[0], WithinAbs( 0, 1e-12 ) );
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to set the 1e-12 epsilon value dependent on the precision, otherwise tests will fail when using single precision (float)

// Input file
auto inputfile = "core/test/input/solvers.cfg";

// State
auto state = std::shared_ptr<State>( State_Setup( inputfile ), State_Delete );

// Reduce precision if float accuracy
double epsilon_apprx = 1e-5;
float epsilon_apprx = 1e-5;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this epsilon be a scalar value?

@GPMueller GPMueller mentioned this pull request Feb 16, 2023
4 tasks
state->active_image->hamiltonian->Gradient_and_Energy( spins, grad, energy3 );

energy1 = state->active_image->hamiltonian->Energy( spins );
REQUIRE( Approx( energy3 ) == energy1 );
REQUIRE_THAT( energy3, WithinAbs( energy1, 1e-4 ) ); // TODO: why the low precision?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The variable energy1 is a float and being compared to a double (if not using CUDA). Maybe it would be better to not re-use energy1 and just declare a new scalar energy4. Then the precision of the test can be set much higher.

@@ -1,38 +1,37 @@
#ifdef SPIRIT_USE_CUDA
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's OK. I can build and run the Code with CUDA. Many of the unit tests fail though, because the requested precision is too high. I think it would be best to use different epsilons for double and single precision builds

== Approx( Engine::Manifoldmath::norm( v1 ) * Engine::Manifoldmath::norm( v2 ) ) );
REQUIRE_THAT(
Engine::Vectormath::dot( v1, v2 ),
!WithinAbs( Engine::Manifoldmath::norm( v1 ) * Engine::Manifoldmath::norm( v2 ), 1e-3 ) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why the requested precision is so much lower here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because there's a not there, we want to be sufficiently far away from the given value

@MSallermann MSallermann merged commit b5fac37 into develop Feb 16, 2023
@GPMueller GPMueller deleted the feature-ci-linting branch February 16, 2023 21:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants