Port extraction class to ParticleInterpolator#174
Conversation
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
mirenradia
left a comment
There was a problem hiding this comment.
Thanks for the PR :) I have some minor comments but I think they should mostly be straightforward to fix.
|
Hi, I added some very minor comments, so I think once you have addressed Miren's changes this is good to go! I do think we need a simpler version of the spherical extraction class, but we can either amend these classes later or maybe just add an additional class called |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
2 similar comments
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
166db22 to
deca1dd
Compare
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
1 similar comment
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
|
Hi @mirenradia @KAClough I have addressed you comments. Please have a look and let me know. I replied directly to your comments in cases where it was not a straightforward fix. I have linter issues, but will resolve them once you are happy with the rest of the changes. |
@tamaraevst, I won't be able to re-review this until next week if that influences whether you want to start fixing the linter issues rather than waiting for me. |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
3 similar comments
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
* Ported CustomExtraction * Ported SurfaceExtraction * Ported SphericalExtraction * Ported WeylExtraction
* Updated BinaryBH example with GW extraction * Some rewrite of Extraction* classes * Added a new file to store StateType * Ported SphericalExtraction test * Remove old files
* Restructure SurfaceExtraction class * Rename CustomExtraction to LineExtraction and make it more general * Some minor renaming of variables and minor commenting
* Renamed params_t structs in Spherical and Surface Extractions * Moved params_t outside of the classes in Spherical and Surface Extractions (to avoid magic numbers in ExtractionTagger and SimulationParametersBase) * Tidied up "include" order in tests * Removed redundant state_index arg in interp() function of the ParticleInterpolator
* Moved extraction parameters to separate files * Added some error checks/messages
* Fix arena init size to 0 in the input file * Remove some unenecessary debugging statements * Fix some linter issues
* Switched to using RoundOffLo() and RoundOffHi() instead of ProbLo and ProbHi * Added a check when the interpolation point lies on the symmetry axis and interpolation stencil needing adjustments
de44b6a to
9718c11
Compare
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
|
Hi all, I have now resolved the two issues concerning the gitlab failing runs. First, I changed the CI for gitlab in the form that Miren suggested here. Second, the gitlab run was failing when running the I also thought that it would be appropriate to use e.g. |
|
Just to note that I tried running this on LUMI-G and with multiple GPU nodes I get a segfault (but not with a single node). Have you tried this @tamaraevst or @mirenradia ? |
Nope, I only have access to 1 GPU. Do you have a backtrace/log file? |
|
It only seems to happen when I use 8 nodes, maybe it is a LUMI problem specifically. This is the backtrace - I only get the ones for 32-63. |
Looks like this is coming from |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
|
This PR modifies the following files which are ignored by .lint-ignore: Please consider removing the corresponding patterns from .lint-ignore so that these files can be linted. |
This is the first draft for porting all of the
Extraction*classes to GRTeclyn and addressing issue #16. Key features:SphericalExtractionfromSurfaceExtractionis the same.ParticleInterpolator.SphericalExtractionhas also been ported. We treat spherical harmonics as state variables there. This choice was deliberate as the above was an "indirect" tests for derived-like variables.I have a couple of comments in regards to the current structure, which I find sub-optimal:
SphericalExtractionparameters are stored inSimulationParametersBase. Because ourParticleInterpolatoris templated over the number of components we are interpolating over,SphericalExtractionneeds to inherit the exact same template. Now, this means inSimulationParametersBasewe need to instate this number of components. Currently, it is hard-coded as a number. One would have hoped that it would be possible to useBHAMR<BinaryBHLevel::num_punctures>::particle_num_componentsbut this results in circular includes. The only improvement I could come up with is storingparticle_num_componentselsewhere (e.g. in some extraction specific struct).StateTypeto a separate file, as I was again hitting circular includes. Was there a reason for defining it globally insideGRAMRLevel?