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

Like4like #6

Open
wants to merge 40 commits into
base: master
Choose a base branch
from
Open

Like4like #6

wants to merge 40 commits into from

Conversation

mtwest2718
Copy link

This pull request over the work in ticket #1

  • Generate a .h5 file for every IDL .dac file created
    • All 1D and 3D arrays in save_varfiles
    • The 1D arrays for grid points save_coordinates
    • All the 3D arrays in def_varfiles
  • Compare the two outputs to make sure they are numerically consistent using compare_output.py in ./idl2hdf5 directory.

The new subroutine that saves individual arrays as hdf5 files is save_param_hdf5 in IO_rot.f90 (lines 339-377).

The one remaining save as .dac subroutine that hasn't been mirrored as a hdf5 call is saving the time coordinates. At some point this needs to be completed but at this stage, I believe #1 is complete.

omar.jamil and others added 30 commits September 28, 2021 20:51
… to allow the code to compile under gcc10 that has stricter fortran standards implemented (https://gcc.gnu.org/gcc-10/porting_to.html)
@mtwest2718 mtwest2718 added the enhancement New feature or request label Jan 20, 2022
@mtwest2718 mtwest2718 self-assigned this Jan 20, 2022
@@ -306,12 +306,12 @@ subroutine BiCGstabMPI(matrix,te,source,count)
double precision,intent(inout)::te(ix,jx,kx),source(ix,jx,kx)
double precision residual(ix,jx,kx)
integer i,j,k,n
double precision total_resi,total_source,tmp
double precision total_resi(1),total_source(1),tmp
Copy link

@omarjamil omarjamil Jan 20, 2022

Choose a reason for hiding this comment

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

It is worth noting that the changes in this file are related to compiling with newer gfortran compiler and not hdf5 changes.

Copy link
Author

Choose a reason for hiding this comment

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

Was this one of your changes at the beginning because I do not remember making this?

Choose a reason for hiding this comment

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

Yes, I made that change.

IO_rot.f90 Outdated
close(mf_z)
close(mf_dz)
! now save as hdf5
call save_param_hdf5(z, "z.dac." // tmp_id, 1, (/INT(kx, KIND=8)/))

Choose a reason for hiding this comment

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

I thought the idea was to have the type conversion take place in the save_param_hdf5 subroutine and not at call time. That would make the interface and call a bit cleaner.

Copy link
Author

Choose a reason for hiding this comment

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

I would like to make the interface & call cleaner but could not figure out how, particularly since I am using the same subroutine to save both 1D and 3D arrays.

Copy link

@omarjamil omarjamil left a comment

Choose a reason for hiding this comment

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

I have a few comments about various changes that seem to inappropriate for the main branch merge. Also, the output *h5 files should not be added to the repo; they might be useful for test/examples directory where you could test your installation, but that is not being done at this stage.

IO_rot.f90 Outdated
call save1param(Nexcite(:,:,:,1),tno//'nexcite1.dac.',1)
call save1param(Nexcite(:,:,:,2),tno//'nexcite2.dac.',1)
call save1param(Nexcite(:,:,:,3),tno//'nexcite3.dac.',1)
call save1param(Nexcite(:,:,:,4),tno//'nexcite4.dac.',1)
call save1param(Nexcite(:,:,:,5),tno//'nexcite5.dac.',1)
call save1param(Nexcite(:,:,:,6),tno//'nexcite6.dac.',1)
! analogous save commands for HDF5 files
call save_param_hdf5(Nexcite(:,:,:,1), "nexcite1.dac.", 3, (/INT(ix, KIND=8), INT(jx, KIND=8), INT(kx, KIND=8)/))

Choose a reason for hiding this comment

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

See comment above about type conversion in the subroutine.

IO_rot.f90 Outdated
!
! Saving a single variable array (of arbitrary rank) to an hdf5 file
!
subroutine save_param_hdf5(data, varname, rank, dims)

Choose a reason for hiding this comment

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

The type conversion of the dummy arguments should take place here.

Copy link
Author

Choose a reason for hiding this comment

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

I just pushed some changes that moves dims declaration inside save_param_hdf5. Makes the calls a lot cleaner.

Copy link
Author

Choose a reason for hiding this comment

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

If I could figure out a way to get rank & dim-size from the data array inside the subroutine, rank and the explicit dims declarations would be unnecessary.

@@ -25,30 +25,30 @@ MOD_FILES = util_rot.mod globalvar.mod parameters.mod \
boundary_rot.mod solver_rot.mod matrix_rot.mod initial_rot.mod procedures.mod

#FC = gfortran
FC = mpif90 -O2
#FC = mpif90 -O2
FC = h5pfc

Choose a reason for hiding this comment

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

This is breaking change for anyone using the code right now without hdf5 present. h5pfc is wrapper/helper script for compiling with hdf5. This is not ready to go into main branch as it is. At the very least need to have some kind of flag option to not use this if you want to use the current code configuration.

Copy link
Author

Choose a reason for hiding this comment

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

Again, this is just a merge into the main on our local fork, not production.

@@ -0,0 +1,16 @@
# needed & optional software libraries

Choose a reason for hiding this comment

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

This may not for the main branch or perhaps some context for the dependency list. At this stage perhaps something for notes rather than added to the code base.

@@ -0,0 +1,7 @@
Use the helper script to compile mpi against hdf5

Choose a reason for hiding this comment

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

Also for notes and not the main branch.

@@ -0,0 +1,133 @@
!

Choose a reason for hiding this comment

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

Not for the main branch commit.

@@ -0,0 +1,8 @@
#!/bin/bash

Choose a reason for hiding this comment

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

This platform dependent so needs to be clarified. Perhaps something for an "examples" directory.

@@ -0,0 +1,101 @@
Data/:outdir; output directory (This should written at the first line in this file!!)

Choose a reason for hiding this comment

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

This should also reside in an examples directory.

@mtwest2718
Copy link
Author

To be clear, this Pull Request is just within UniExeterRSE's fork of the PIP code-base. None of dev-test material will be going out to the production repo when we finish up the development. I can write another issue as a reminder to remove all of those scripts, directories and the like before merging into @AstroSnow main repository. Would that be satisfactory @omarjamil?

@mtwest2718 mtwest2718 requested a review from omarjamil January 20, 2022 14:56
Copy link

@omarjamil omarjamil left a comment

Choose a reason for hiding this comment

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

I appreciate this is all on the fork, but still good to have a gold standard branch, master in this case. This a work-in-progress code review and all of the things being committed will likely create confusion on the master branch down the line e.g. when creating a pull request with Ben's upstream branch would need to remember and know which files to remove and move around (e.g. output files should not be added). If you keep the master branch merges as clean and as working (suitable for regression testing) then that would likely save time in the future. I am happy to review and have this conversation, but not sure this needs to go in the master just yet. Perhaps make this a draft pull request instead.

character(len=40) :: fpath ! Relative path for output file

! Define file path based on rank type
if (rank.eq.3) then

Choose a reason for hiding this comment

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

It is good to see type casting moved into the subroutine. I guess ix,iy,iz are globals. This something Ben that might know better, but my concern with this approach is whether ix,iy,iz would need to be different when collecting all the data from all the processors? When I was thinking about type casting within the subroutine, I was thinking about doing something like this: h5screate_simple_f(rank, INT(dims, KIND=8), dspace_id, error). That would keep it general, but needs testing as I am not sure it will work.

Copy link
Author

Choose a reason for hiding this comment

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

Good point on regression testing.

  • Should I close this Pull Request without merging, then?
  • I might as well change the name of this branch to dev to contrast that with main and not have it be so specifically tied to a single issue.

Copy link
Collaborator

Choose a reason for hiding this comment

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

ix, iy, iz are local variables. You might need to create a global version (ixg?) that would need to be allocated in MPI_rot.f90 (before line 26 which is where ix, iy, iz become local). There is also the set_mpi_pos subroutine that is used to determine the location of each processor so this could be useful when collating the data.

@omarjamil
Copy link

Having a dev branch is a good idea. You could create a new one and move the most relevant changes onto there. Could be a good opportunity to have atomic commits there. Then have a draft PR running between us for reviews and discussions on the implementations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants