-
Notifications
You must be signed in to change notification settings - Fork 371
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
On PM-CPU, WaveWatchIII text input file takes too long to read in. #6670
Comments
Why aren't these in netcdf format? You can never read that large of text file fast. |
First, just sanity check of transfer speeds from CFS, CFS with dvs_ro, and scratch, I tried simple experiment below to show that they are all "about the same" in this scenario. I think dvs_ro is generally only faster with smaller file sizes, but... as to Rob's point, as these are text files, they are likely NOT being read in parallel method. If possible, better to use diff file format with diff supported mechanisms to read in parallel. But if reading in text "manually", you for sure don't want to each MPI rank reading the entire file all at the same time. I don't yet know if that's happening here. Yes, this will be slower (how much slower really depends), but more importantly, it's error-prone and can cause filesystem problems (esp with increasing MPI ranks -- including other jobs trying to read same file). You could put together a quick patch to have rank0 read the file and use MPI_Bcast() to communicate data to other ranks.
|
As reading an ASCII or small file seems like a recurring pattern, I would suggest we put in a read and broadcast operation in Scorpio and have everyone use it rather than everyone implement this in their sub-model. Of course, it's trivial to do this right but one reusuable routine is better for maintenance. cc @jayeshkrishna The best path is to have any input files to be read in parallel to be in netCDF. |
The better place for that would be E3SM/share/util. SCORPIO should remain focused on large scale parallel reads/writes. |
@ndkeen - I'm pretty sure WW3 IS, in fact, reading the entire file with each task. not good. |
@erinethomas Just for clarification - is this occurring in source under our control? i.e. Does this occur within the WWIII source? Or are these reads taking place within MPAS for use in WWIII? |
This is happening within the WW3 source (not in MPAS) - we have a fork of WW3 source code for use within E3SM (as a submodule) that we have full control over and can modify to suit our needs. |
So it seems like the most appropriate solution (besides changing the file location) is to modify the WWIII source. If this is reading a table or set of values that are shared by all tasks, we should do a read from master and broadcast. If the values are meant to be distributed (ie each task needs a subset of values), we should do a proper parallel I/O. Let us know if you need help - the broadcast is relatively easy, but the parallel I/O is a bit more involved. |
A few comments: |
Can you please post a way to reproduce this issue? |
it will be easiest to reproduce after the ICOS mesh for WaveWatchIII PR is finalized (#6706). I will post as soon as that is complete. |
WW3 requires two large text files to be read in during the wave model initialization (the unresolved obstacles files).
These files are stored on global CFS with the rest of the E3SM data:
/global/cfs/cdirs/e3sm/inputdata/wav/ww3/obstructions_local.wQU225Icos30E3r5sp36x36.rtd.in. (size = 348M)
/global/cfs/cdirs/e3sm/inputdata/wav/ww3/obstructions_shadow.wQU225Icos30E3r5sp36x36.rtd.in (size = 626M)
These files take too long to be read in (often, simulations result in errors due to the wall clock time running out for short tests). For example, I have run the following tests:
These initialization times are WAY too long. It also suggests the problem scales with the number of nodes (twice as many nodes take about twice as much time to initialize the model)
I have found two possible solutions/workarounds that possibly suggest the issue is reading the big files from the global CFS directory
The text was updated successfully, but these errors were encountered: