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

Add multiple parallel slices #1345

Merged
merged 38 commits into from
Feb 12, 2019
Merged

Add multiple parallel slices #1345

merged 38 commits into from
Feb 12, 2019

Conversation

ZedThree
Copy link
Member

@ZedThree ZedThree commented Oct 29, 2018

Nothing uses the extra parallel slices yet -- waiting for the derivatives work to be finished.

See #1336 for some discussion

@ZedThree ZedThree added the work in progress Not ready for merging label Oct 29, 2018
@ZedThree ZedThree added this to the BOUT-4.3 milestone Oct 29, 2018
include/field3d.hxx Outdated Show resolved Hide resolved
src/field/field3d.cxx Show resolved Hide resolved
@@ -226,30 +228,42 @@ class Field3D : public Field, public FieldData {

/// Check if this field has yup and ydown fields
bool hasYupYdown() const {
return (yup_field != nullptr) && (ydown_field != nullptr);
return !yup_fields.empty() and !ydown_fields.empty();
Copy link
Contributor

Choose a reason for hiding this comment

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

If we added a bool hasValidYUpDown, could be return hasValidYUpDown, since if mergeYupYdown() has been called, then calling yup(), etc., should be allowed so this should return true even if yup_fields is empty.

I'd been deleting yup/ydown fields on #1176, but now I've changed that to calling setHasValidYUpDown(false). 4a7cbcf is meant to have all the places that yup/ydown should be marked as invalid.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it might just be cleaner to delete the parallel slices where we need to invalidate them. I'm not sure there's anything to be gained from keeping them

Copy link
Contributor

Choose a reason for hiding this comment

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

👍 am I right in thinking that the std::vector will not deallocate when we call clear, so we're not actually losing anything by deleting them?

Copy link
Member Author

Choose a reason for hiding this comment

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

std::vector::clear erases its contents, so the values will be lost but it does retain its capacity though, so next time we create the parallel slices we won't need to allocate any new memory, if that's what you meant.

This changes the behaviour of mergeYupYdown: afterwards, the parallel
slices are not valid
* next: (93 commits)
  Fix use of abs in fieldgenerators
  Fix use of abs in utils.hxx
  Fix use of abs in cyclic_reduction
  Fix use of abs in imex-bdf2 solver
  Fix abs use in slepc solver
  Fix use of abs in rkgeneric
  Improve some comments; use uniform initialisation more consistently
  Use `Options::force` to overwrite options quietly
  Default initialise field sizes and Field::bndry* status
  Default initialise boundaryIs{Copy,Set} in FieldData
  Default initialise some Field3D/2D members
  Add move constructor for Field2D
  Add swap function for Field2D
  Add move constructor for Field3D
  Make test-command-args quieter
  Add test for clobbering datadir from commandline
  Fix:Escaping in makefile
  Documentation improvements
  Improve documentation
  Make sure command line short-options override options file settings
  ...
@ZedThree
Copy link
Member Author

I think this is the right direction to go in, but unfortunately, it changes both the semantics and behaviour in a backwards-incompatible fashion.

Field3d::mergeYupYdown() no longer makes f.yup() identified with f, it clears all the parallel slices. I could change it so that it instead essentially does the identity transform, but it would still mean that:

f.mergeYupYdown();
&f.yup() == &f;

would no longer hold. Is this acceptable?


This PR needs to make the non-trivial parallel transforms actually calculate multiple parallel slices for it to be useful. I'm working on writing some sanity/unit tests for the shifted metric so that I can change that happily.

@johnomotani
Copy link
Contributor

👍 I think the backwards-incompatibility is acceptable; anyone who has physics-model code that would notice the change is surely following next development closely enough not to be confused!

ZedThree and others added 14 commits January 14, 2019 11:03
* next: (347 commits)
  Parameterise FFT tests over both even- and odd-length real signals
  Fix bug in `irfft(Array)`: length of original signal is needed
  Add Array::resize to simplify changing the size of an Array
  Use type alias instead of typedef
  Move ShiftedMetric::cmplx/cmplxLoc into shiftZ; make shiftZ const
  Fix shiftedmetric test fixture
  Move some initial setup into ShiftedMetric test fixture
  Add more ShiftedMetric tests
  Add region argument for test field-field comparisons
  Basic test for shiftedmetric
  Add test helpers for filling Fields with values
  Move map and function definitions into source file for bout_types
  Support loc argument to Laplacian::tridagCoefs
  Fix elm-pb MMS test boundary conditions
  Remove deprecated invert_laplace functions from tests
  Deleting unused example code
  Almost all invert_laplace calls removed
  Removing more invert_laplace uses
  Make absence of fftw-wisdom non-fatal in configure
  Use unique_ptr for LaplaceXZcyclic::cr
  ...
Forward-FFT whole field, then inverse-FFT for each parallel
slice. Will make it easier to generalise to multiple parallel slices
@ZedThree ZedThree removed the work in progress Not ready for merging label Jan 15, 2019
@ZedThree
Copy link
Member Author

I think this is about ready to go in. I've not added support for multiple parallel slices to FCI yet. Requires some thinking about.

I'm also pondering deprecating the current yup/ydown, etc. methods and replacing them with:

// Call mesh->getParallelTransform().calcYupYdown()
void createParallelSlices();
// Delete parallel slices; replace mergeYupYdown
void clearParallelSlices();
// Replace hasYupYdown
bool hasParallelSlices() const;
// Replace yup/ydown/ynext
Field3D& getParallelSlice(int dir);

@bshanahan
Copy link
Contributor

bshanahan commented Jan 15, 2019 via email

@johnomotani
Copy link
Contributor

johnomotani commented Jan 15, 2019

this could be slightly slower (to call getparallelslice 2-4 times per derivative function).

@bshanahan it's OK: if you set MYG=1 in the options (or mesh), so there's only one guard cell in the y-direction, then it'll only calculate 2 parallel slices instead of 4.

@@ -207,14 +207,13 @@ template <typename T>
T DDY(const T& f, CELL_LOC outloc = CELL_DEFAULT, const std::string& method = "DEFAULT",
REGION region = RGN_NOBNDRY) {
AUTO_TRACE();
if (std::is_base_of<Field3D, T>::value && f.hasYupYdown()
&& ((&f.yup() != &f) || (&f.ydown() != &f))) {
if (std::is_base_of<Field3D, T>::value && f.hasYupYdown()) {
Copy link
Member

Choose a reason for hiding this comment

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

This hasn't changed, but this condition means that Field2D always goes through the "aligned" branch. It should actually equally be able to go through the orthogonal branch without any issue now (the previous case was that f.yup() != &f would always be false for Field2D so it would always go through the second branch anyway, so the Field3D check was just a compile-time way of ensuring this). I'm not sure which is preferred/more efficient etc. but might be worth experimenting with.

Secondly I think you proposed providing alternative names rather than yup/ydown -- is it worth using the new name in the function here (i.e. f.hasParallelSlices() rather than f.hasYupYdown()), or have these renames not happened yet?

Copy link
Member Author

Choose a reason for hiding this comment

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

It would be nice to be able to treat them the same!

Renames haven't happened, I was thinking of doing them in another PR in case there was any discussion on the names, but happy to just do them here (names can always be changed before the next release)

@ZedThree
Copy link
Member Author

I think this is about done finally.

I'll make separate PRs for introducing nicer synonyms for yupydown stuff and further tidying up of the parallel transforms.

include/interpolation.hxx Outdated Show resolved Hide resolved
include/stencils.hxx Show resolved Hide resolved
src/mesh/parallel/shiftedmetric.cxx Outdated Show resolved Hide resolved
src/mesh/parallel/shiftedmetric.cxx Outdated Show resolved Hide resolved
tests/integrated/test-smooth/test_smooth.cxx Outdated Show resolved Hide resolved
tools/pylib/zoidberg/test_zoidberg.py Outdated Show resolved Hide resolved
@d7919 d7919 requested a review from bendudson February 1, 2019 11:57
bendudson
bendudson previously approved these changes Feb 4, 2019
Copy link
Contributor

@bendudson bendudson left a comment

Choose a reason for hiding this comment

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

Thanks @ZedThree ! Some small things, but looks good. Thanks for all the tests.

* next: (99 commits)
  Fix typo in documentation
  Silence warnings in MMS/time
  Remove some commented out bits from MMS/time
  Test fix: don't use adaptive time stepping when measure time scaling
  Further generalise derivatives unit test to fourth order methods
  Fix comments in derivatives test
  Be more generous with allowed order to count as pass
  Add line to trace manipulation section
  Update unit tests for assignment from non-finite
  Fix typo
  Allow assignment with non-finite but allocated data
  Fix links in intro
  Add section on analyzing/manipulating trace files
  Add Extrae+Archer info
  Update intro to include Extrae/Paraver
  Remove setLocation() in Field3D::operator=(FieldPerp)
  Add helper function for filling fields with function at each point
  Test all first and second derivatives in X, Y and Z
  Actually remove the checkData calls
  Update unit tests for checkData removals
  ...
Should be done better by actually calculating the arc length of the
field line
@ZedThree
Copy link
Member Author

ZedThree commented Feb 5, 2019

Ok, think this is finally, finally done!

johnomotani
johnomotani previously approved these changes Feb 12, 2019
@dschwoerer dschwoerer mentioned this pull request Feb 12, 2019
* next: (57 commits)
  Make messages(de) more consistent
  Fix expr.hxx
  Improve translation
  Update name pf helper function
  Add German translation
  Update generated file
  Extend README
  String changes for translation
  Auto: update libbout.pot
  Replace IsField*Equal* predicates with templated versions
  Use nullptr as default Mesh* argument for Laplacian::create
  Fix bug in DST option for cyclic solve
  Add initial simple tests for advection derivatives
  Increase grid size used in test_derivs unit tests
  Add 'using namespace bout::globals;' for new unit test files.
  Ignore hidden and temporary files
  Pass mesh_in in initializer list of FCIMap::FCIMap constructor
  Pass parameter pack by forwarding-ref, function by const-ref
  Use bout::globals::dump in BOUTMAIN macro
  Use bout::globals::dump in SlepcSolver
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants