Potential race condition in base GNUmakefile examples target #68
Assignees
Labels
bug
Something isn't working
Comments
mirenradia
added a commit
that referenced
this issue
Jul 19, 2024
This adds a base Makefile that should be common to GRTeclyn examples (once there is more than one) and eventually the tests too. There is also a new amrex-objects target in the root makefile which should fix #68 as it is a dependency of the examples targets although this does rely on the examples keeping the same default configuration (i.e. USE_MPI = TRUE, COMP = gnu). I have added a base name to the BinaryBH example.
mirenradia
added a commit
that referenced
this issue
Dec 20, 2024
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
mirenradia
added a commit
that referenced
this issue
Dec 20, 2024
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
mirenradia
added a commit
that referenced
this issue
Dec 23, 2024
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
julianakwan
pushed a commit
that referenced
this issue
Dec 23, 2024
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
mirenradia
added a commit
that referenced
this issue
Jan 7, 2025
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
julianakwan
pushed a commit
that referenced
this issue
Jan 8, 2025
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
|
Fixed in #82. |
julianakwan
pushed a commit
that referenced
this issue
Jan 17, 2025
I think this will help with #68. The disadvantage (and the reason I bothered to set this default in the first place) is that consecutive builds of different AMReX executables (e.g. two different examples) will be slower. To mitigate this, users should use Ccache. I will add this to the CI in a separate PR.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@WeiqunZhang pointed out that the
examplestarget in the baseGNUmakefilehas a potential race condition since all of the individual examples targets will try to build AMReX source files together at the same time if built with parallel jobs.This is why your CI keeps failing for the ScalarField, @julianakwan!
The text was updated successfully, but these errors were encountered: