-
Notifications
You must be signed in to change notification settings - Fork 0
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
base: master
Are you sure you want to change the base?
Like4like #6
Conversation
… to allow the code to compile under gcc10 that has stricter fortran standards implemented (https://gcc.gnu.org/gcc-10/porting_to.html)
…moval of trailing whitespace.
…There ought to be a way to combine them...
…test run_code & settings files.
…ing sim-type comments
…code more width compact
… Also removed commented out old code.
…d the pdb.set_trace() comment.
…iles in idl2hdf5 dir
@@ -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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)/)) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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)/)) |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 @@ | |||
! |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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!!) |
There was a problem hiding this comment.
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.
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? |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 withmain
and not have it be so specifically tied to a single issue.
There was a problem hiding this comment.
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.
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. |
This pull request over the work in ticket #1
.h5
file for every IDL.dac
file createdsave_varfiles
save_coordinates
def_varfiles
compare_output.py
in./idl2hdf5
directory.The new subroutine that saves individual arrays as hdf5 files is
save_param_hdf5
inIO_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.