PnetCDF module #456

wkliao · 2021-08-24T23:24:39Z

Add/update the PnetCDF module.

the default is changed to --disable-pnetcdf-mod
command-line option --with-pnetcdf is added
All PnetCDF APIs are included.
Internal counters and timestamps are now separated for files and variables respectively

shanedsnyder · 2022-07-06T14:53:46Z

I'm reviewing this now, but probably a good starting point here would be to work on rebasing this on top of #726, which increases Darshan's maximum modules from 16 to 64 -- these PnetCDF modules push us beyond our current limits on main. This will require a little bit of work to update the PnetCDF module for changes to Darshan's core API since this PR was submitted.

shanedsnyder · 2022-08-17T21:38:39Z

This is now rebased on our main branch and is working fine for me using IOR+PnetCDF as a test. I'll add more detailed feedback as a review.

darshan-runtime/doc/darshan-runtime.txt

include/darshan-pnetcdf-log-format.h

shanedsnyder · 2022-08-17T23:04:45Z

I started a small review for more concise things, but there are a few things that stood out to me at a high-level that it might be good for us all to discuss:

We will need to decide how exactly we want to provide backwards compatibility (if any at all) to our existing PnetCDF module. Notably, there have been some key changes to counter names that might complicate up-conversion of old PnetCDF records to the new format: PNETCDF_INDEP_OPENS and PNETCDF_COLL_OPENS are completely removed in the new format version, which also defines PNETCDF_CREATES and PNETCDF_OPENS now. We could still upconvert as best we can (maybe combining INDEP_OPENS/COLL_OPENS into OPENS and setting CREATES to -1 when upconverting?). Or we could provide no backwards compatibility and avoid parsing PnetCDF data from logs with old format versions.
For the new PnetCDF file module, there are a lot of timers that we probably wouldn't typically capture. Right now, this module captures _START_TIMESTAMP, _END_TIMESTAMP, and _TIME counters for each operation it instruments (open, create, close, redef, enddef, sync, coll_wait, indep_wait). To better match our level of capture in other modules, I'd suggest we just capture open TIMESTAMP information (with this accounting for opens and creates), and combine all of the cumulative TIME counters into a single META_TIME counter. Part of the reasoning for doing this is that some of our analysis tools kind of expect this format, and it will complicate PnetCDF analysis if it's being a lot more specific, I think.
There are a lot of (560!) wrapped functions. I'd be surprised if they are all supported in all PnetCDF versions, but maybe they are? If not, we probably want to think about how to best handle this (i.e., autoconf checks for functions defined in newer PnetCDF releases, only formally supporting PnetCDF versions that have all of these functions implemented, etc.).

wkliao · 2022-08-18T05:29:52Z

We will need to decide how exactly we want to provide backwards compatibility (if any at all) to our existing PnetCDF module. Notably, there have been some key changes to counter names that might complicate up-conversion of old PnetCDF records to the new format: PNETCDF_INDEP_OPENS and PNETCDF_COLL_OPENS are completely removed in the new format version, which also defines PNETCDF_CREATES and PNETCDF_OPENS now. We could still upconvert as best we can (maybe combining INDEP_OPENS/COLL_OPENS into OPENS and setting CREATES to -1 when upconverting?). Or we could provide no backwards compatibility and avoid parsing PnetCDF data from logs with old format versions.

Like in MPI-IO, file create and open in PnetCDF are collective only. I think using INDEP_OPENS/COLL_OPENS in Darshan was a mistake (and misleading).

wkliao · 2022-08-18T05:32:30Z

For the new PnetCDF file module, there are a lot of timers that we probably wouldn't typically capture. Right now, this module captures _START_TIMESTAMP, _END_TIMESTAMP, and _TIME counters for each operation it instruments (open, create, close, redef, enddef, sync, coll_wait, indep_wait). To better match our level of capture in other modules, I'd suggest we just capture open TIMESTAMP information (with this accounting for opens and creates), and combine all of the cumulative TIME counters into a single META_TIME counter. Part of the reasoning for doing this is that some of our analysis tools kind of expect this format, and it will complicate PnetCDF analysis if it's being a lot more specific, I think.

This sounds fine with me.

wkliao · 2022-08-18T05:37:59Z

There are a lot of (560!) wrapped functions. I'd be surprised if they are all supported in all PnetCDF versions, but maybe they are? If not, we probably want to think about how to best handle this (i.e., autoconf checks for functions defined in newer PnetCDF releases, only formally supporting PnetCDF versions that have all of these functions implemented, etc.).

The last time PnetCDF added new I/O-related APIs was version 1.6.0, released in February 2, 2015. (FYI. the latest release is 1.12.3.) We can make 1.6.0 the minimum requirement in configure.ac. Its Release Note contains all history, just keyword search "New APIs".

carns · 2022-08-18T15:03:35Z

We will need to decide how exactly we want to provide backwards compatibility (if any at all) to our existing PnetCDF module. Notably, there have been some key changes to counter names that might complicate up-conversion of old PnetCDF records to the new format: PNETCDF_INDEP_OPENS and PNETCDF_COLL_OPENS are completely removed in the new format version, which also defines PNETCDF_CREATES and PNETCDF_OPENS now. We could still upconvert as best we can (maybe combining INDEP_OPENS/COLL_OPENS into OPENS and setting CREATES to -1 when upconverting?). Or we could provide no backwards compatibility and avoid parsing PnetCDF data from logs with old format versions.

What if we assigned this module a different ID and just treated them as two separate things? That way if the parser encounters a log with the old-style pnetcdf module it will still emit it in case someone needs that. It doesn't seem worth the effort to up-convert since the scope is so different.

If we go that route (new module id, keep ability to print old module id) then I guess we want to make sure the prefix is slightly different.

I'm not sure about this idea yeah, just wanted to offer it as an idea for discussion.

shanedsnyder · 2022-08-18T16:21:56Z

There are a lot of (560!) wrapped functions. I'd be surprised if they are all supported in all PnetCDF versions, but maybe they are? If not, we probably want to think about how to best handle this (i.e., autoconf checks for functions defined in newer PnetCDF releases, only formally supporting PnetCDF versions that have all of these functions implemented, etc.).

The last time PnetCDF added new I/O-related APIs was version 1.6.0, released in February 2, 2015. (FYI. the latest release is 1.12.3.) We can make 1.6.0 the minimum requirement in configure.ac. Its Release Note contains all history, just keyword search "New APIs".

Awesome, thanks for the details. I'll add in an autoconf check for this version number and will mention in the darshan-runtime docs about the version dependency (though it sounds like these functions are all sufficiently old, that we're unlikely to hit this problem in practice).

wkliao · 2022-08-18T16:22:59Z

Backward compatibility refers to a new version (Darshan parser) being able to read the log files created by an older version. So, when the new parser encountered PNETCDF_INDEP_OPENS and PNETCDF_COLL_OPENS, it should merge them into PNETCDF_OPEN (same for PNETCDF_CREATE).

One question, how does Darshan tell an open/create is independent?

shanedsnyder · 2022-08-18T16:23:17Z

For the new PnetCDF file module, there are a lot of timers that we probably wouldn't typically capture. Right now, this module captures _START_TIMESTAMP, _END_TIMESTAMP, and _TIME counters for each operation it instruments (open, create, close, redef, enddef, sync, coll_wait, indep_wait). To better match our level of capture in other modules, I'd suggest we just capture open TIMESTAMP information (with this accounting for opens and creates), and combine all of the cumulative TIME counters into a single META_TIME counter. Part of the reasoning for doing this is that some of our analysis tools kind of expect this format, and it will complicate PnetCDF analysis if it's being a lot more specific, I think.

This sounds fine with me.

Okay, I'll take a shot at updating the module along these lines.

shanedsnyder · 2022-08-18T16:34:43Z

We will need to decide how exactly we want to provide backwards compatibility (if any at all) to our existing PnetCDF module. Notably, there have been some key changes to counter names that might complicate up-conversion of old PnetCDF records to the new format: PNETCDF_INDEP_OPENS and PNETCDF_COLL_OPENS are completely removed in the new format version, which also defines PNETCDF_CREATES and PNETCDF_OPENS now. We could still upconvert as best we can (maybe combining INDEP_OPENS/COLL_OPENS into OPENS and setting CREATES to -1 when upconverting?). Or we could provide no backwards compatibility and avoid parsing PnetCDF data from logs with old format versions.

What if we assigned this module a different ID and just treated them as two separate things? That way if the parser encounters a log with the old-style pnetcdf module it will still emit it in case someone needs that. It doesn't seem worth the effort to up-convert since the scope is so different.

If we go that route (new module id, keep ability to print old module id) then I guess we want to make sure the prefix is slightly different.

I'm not sure about this idea yeah, just wanted to offer it as an idea for discussion.

I think one key downside to this approach is just that utilities would have to be aware of both formats (old/new) and try to handle gracefully. It probably would just simplify things generally for us to only expose the new format going forward?

Looking closer, the only issue with the up-conversion is just that there are no longer INDEP_OPENS and COLL_OPENS counters, so we have to combine them into a single counter now in the new format. I'm not sure that's really a big deal, especially if we are making the call going forward that there's not really a distinction between INDEP_OPENS and COLL_OPENS. That is, if we think it's important enough to distinguish between these, then they ought to be accounted for in our new counters -- Wei-Keng seems to think the distinction is misleading, so maybe they really should just be cut entirely?

Also, FWIW, we've already taken a similar approach in the HDF5 module, in that it was previously a barebones module that is now being upconverted into the new more detailed format.

shanedsnyder · 2022-08-18T16:39:59Z

One question, how does Darshan tell an open/create is independent?

Looks like in the PnetCDF module, an open is marked as independent if the input communicator size == 1. I'm not sure it's semantically useful to capture that distinction, though. Presumably if the input communicator only contains 1 process, it will be clear from the rank information captured by Darshan how many processes opened it?

carns · 2022-08-18T17:31:54Z

Looking closer, the only issue with the up-conversion is just that there are no longer INDEP_OPENS and COLL_OPENS counters, so we have to combine them into a single counter now in the new format. I'm not sure that's really a big deal, especially if we are making the call going forward that there's not really a distinction between INDEP_OPENS and COLL_OPENS. That is, if we think it's important enough to distinguish between these, then they ought to be accounted for in our new counters -- Wei-Keng seems to think the distinction is misleading, so maybe they really should just be cut entirely?

Also, FWIW, we've already taken a similar approach in the HDF5 module, in that it was previously a barebones module that is now being upconverted into the new more detailed format.

That makes sense. Upconverting seems reasonable to me.

carns · 2022-08-18T17:33:10Z

One question, how does Darshan tell an open/create is independent?

Looks like in the PnetCDF module, an open is marked as independent if the input communicator size == 1. I'm not sure it's semantically useful to capture that distinction, though. Presumably if the input communicator only contains 1 process, it will be clear from the rank information captured by Darshan how many processes opened it?

Yeah, that's right. I agree it's not a useful counter distinction for pnetcdf moving forward.

shanedsnyder · 2022-08-18T18:18:58Z

There are a lot of (560!) wrapped functions. I'd be surprised if they are all supported in all PnetCDF versions, but maybe they are? If not, we probably want to think about how to best handle this (i.e., autoconf checks for functions defined in newer PnetCDF releases, only formally supporting PnetCDF versions that have all of these functions implemented, etc.).

The last time PnetCDF added new I/O-related APIs was version 1.6.0, released in February 2, 2015. (FYI. the latest release is 1.12.3.) We can make 1.6.0 the minimum requirement in configure.ac. Its Release Note contains all history, just keyword search "New APIs".

Awesome, thanks for the details. I'll add in an autoconf check for this version number and will mention in the darshan-runtime docs about the version dependency (though it sounds like these functions are all sufficiently old, that we're unlikely to hit this problem in practice).

@wkliao -- is there a reliable way to grab the PnetCDF library version across versions that you recommend? I found pnetcdf_version program which looks like it would work, but wasn't sure if there was another preferred method.

wkliao · 2022-08-18T18:25:37Z

In PnetCDF header file, pnetcdf.h, there are a few C constants defined for version numbers. Below is an example.

#define PNETCDF_VERSION       "1.11.2"
#define PNETCDF_VERSION_MAJOR 1
#define PNETCDF_VERSION_MINOR 11
#define PNETCDF_VERSION_SUB   2

shanedsnyder · 2022-08-18T18:26:36Z

There are a lot of (560!) wrapped functions. I'd be surprised if they are all supported in all PnetCDF versions, but maybe they are? If not, we probably want to think about how to best handle this (i.e., autoconf checks for functions defined in newer PnetCDF releases, only formally supporting PnetCDF versions that have all of these functions implemented, etc.).

The last time PnetCDF added new I/O-related APIs was version 1.6.0, released in February 2, 2015. (FYI. the latest release is 1.12.3.) We can make 1.6.0 the minimum requirement in configure.ac. Its Release Note contains all history, just keyword search "New APIs".

Awesome, thanks for the details. I'll add in an autoconf check for this version number and will mention in the darshan-runtime docs about the version dependency (though it sounds like these functions are all sufficiently old, that we're unlikely to hit this problem in practice).

@wkliao -- is there a reliable way to grab the PnetCDF library version across versions that you recommend? I found pnetcdf_version program which looks like it would work, but wasn't sure if there was another preferred method.

To answer my own question from the release notes:

-------------------------------------
Version 1.5.0 (July 8, 2014)
-------------------------------------
...
  o New utility program
    * pnetcdf_version prints the version information of the PnetCDF library and
      command-line arguments used at configure

I'll just use this unless you have any objections.

shanedsnyder · 2022-08-18T18:27:50Z

In PnetCDF header file, pnetcdf.h, there are a few C constants defined for version numbers. Below is an example.
#define PNETCDF_VERSION       "1.11.2"
#define PNETCDF_VERSION_MAJOR 1
#define PNETCDF_VERSION_MINOR 11
#define PNETCDF_VERSION_SUB   2

Ahh, thanks. I'll try this out.

wkliao · 2022-08-18T18:32:29Z

Here is a code fragment I have been using.
https://github.com/Parallel-NetCDF/E3SM-IO/blob/7696d8901fa0680b0b89f4e42a8a497e5d23a533/configure.ac#L321-L336

shanedsnyder · 2022-08-19T19:44:41Z

Autoconf code enforcing library version >= 1.6.0 has been pushed via bd6369a

shanedsnyder · 2022-08-23T17:38:46Z

For the new PnetCDF file module, there are a lot of timers that we probably wouldn't typically capture. Right now, this module captures _START_TIMESTAMP, _END_TIMESTAMP, and _TIME counters for each operation it instruments (open, create, close, redef, enddef, sync, coll_wait, indep_wait). To better match our level of capture in other modules, I'd suggest we just capture open TIMESTAMP information (with this accounting for opens and creates), and combine all of the cumulative TIME counters into a single META_TIME counter. Part of the reasoning for doing this is that some of our analysis tools kind of expect this format, and it will complicate PnetCDF analysis if it's being a lot more specific, I think.

This should be done via 1792807.

There is one additional simplification we could consider in that we could just get rid of the PNETCDF_FILE_CREATES counter and just track it with PNETCDF_FILE_OPENS. We have similar approaches in POSIX and MPI-IO modules, in that we don't explicitly track create counters since there's no way to tell whether they are actually creating the underlying file -- if the file already exists, these calls behave much like vanilla open calls. I'd prefer to borrow this same approach in the PnetCDF module, unless we think it's really important to know whether users are using open vs create. What do you guys think?

wkliao · 2022-08-23T18:25:37Z

Is the same implemented for HDF5? given H5Fcreate and H5Fopen are two separate APIs.

shanedsnyder · 2022-08-23T18:42:58Z

Is the same implemented for HDF5? given H5Fcreate and H5Fopen are two separate APIs.

The HDF5 module bins both of those calls up into HF5_OPENS counter, so this change would be consistent with that, too.

wkliao · 2022-08-23T18:48:20Z

I am wondering whether separating the counters can be useful for
metadata intensive applications, e.g. create/open a lot of files in the
one-file-per-process I/O pattern. In modern parallel file systems, will
the cost of file creation be significantly different from opening? If it
is not, then keeping separate counters makes less sense.

darshan-runtime/lib/darshan-pnetcdf-api.m4

shanedsnyder · 2022-08-24T16:17:23Z

I am wondering whether separating the counters can be useful for metadata intensive applications, e.g. create/open a lot of files in the one-file-per-process I/O pattern. In modern parallel file systems, will the cost of file creation be significantly different from opening? If it is not, then keeping separate counters makes less sense.

I agree it's useful to be able to distinguish opens/creates in the theoretical sense, since they likely have different performance characteristics on different systems. We maybe have just been careful binning things in a CREATE counter in the past to avoid potential confusion, in that calling create variants of different I/O calls doesn't really ensure the underlying file was created (rather than just opening an existing file) -- this is probably especially true for POSIX open() calls that by habit keep O_CREAT flag set, but maybe it's not as typical to use create variants of PnetCDF/HDF5 calls like this. It's possible users could see lots of CREATE counters in there job summary report and incorrectly come to conclusion that there job created lots of files, if they were just using create APIs to open existing files.

That's just some background on why I think we've avoided CREATE counters in other modules. That said, this isn't a really big deal if PnetCDF wants to do something different, so if you think it's useful to capture, we can keep the additional counter. I just wanted to mention it now, since we can't really remove the counter easily once it's added, so better to think about now.

shanedsnyder · 2022-08-24T16:18:29Z

I added a more detailed review that captures most of my comments/feedback for the PnetCDF wrappers contained in the m4 code. I'm happy to make the code changes necessary to address these, just wanted to make sure you had a chance to respond to any feedback.

shanedsnyder · 2022-08-24T16:19:59Z

I'll use this comment to keep track of things that aren't currently tracked in a review comment, but that we would like to see addressed before merging this in.

add backwards compatibility code to up-convert old versions of PnetCDF module to current version introduced in this PR
add CFFI bindings for new PnetCDF record structures in pnetcdf-log-format.h
add PnetCDF module data to I/O cost graphs, as well as add a new PnetCDF module summary section to PyDarshan summary reports

- this allows Darshan to capture whether variables are record variables or not

* allows minimal PnetCDF data captured in prior versions of Darshan to be upconverted to new module formats so it can be parsed by users

shanedsnyder · 2022-10-27T22:41:02Z

darshan-util/pydarshan/darshan/experimental/aggregators/mod_agg_iohist.py

@@ -12,7 +12,7 @@ def mod_agg_iohist(self, mod, mode='append'):
    """

    # sanitation and guards
-    supported = ["POSIX", "MPI-IO", "H5D"]
+    supported = ["POSIX", "MPI-IO", "H5D", "PNETCDF_VAR", "PNETCDF_FILE"]


@tylerjereddy just noticed this when doing a final read-through

I think we can remove PNETCDF_FILE from the supported list, as there are no access histogram counters in the file-level records for PnetCDF (they are stored in the variable-level counters). I removed locally and tests pass, so just wanted to double check there wasn't a reason before removing.

In the changes to cli/summary.py you can see there are similar guards for supported modules for I/O histograms that does not include PNETCDF_FILE, which makes total sense, so I just removed it from the supported list here, too. Must have been an oversight.

shanedsnyder · 2022-10-27T22:56:04Z

darshan-util/pydarshan/darshan/cli/summary.py

@@ -436,15 +436,21 @@ def register_figures(self):
            opcounts_mods.append("H5D")
        elif "H5F" in self.report.modules:
            opcounts_mods.append("H5F")
+        elif "PNETCDF_VAR" in self.report.modules:


@tylerjereddy Shouldn't this be if rather than elif, otherwise we'd run into issues if a log had both PnetCDF and HDF5 modules active? i.e., use an if/elif block for HDF5 and a separate if/elif block for PnetCDF

Probably, and can't the same be said for the elif above as well with the new config modularity? I suspect we need more test files to catch that stuff.

I fixed s.t. a different if/elif clause is used for PNETCDF_FILE/PNETCDF_VAR than for H5F/H5D. Otherwise, it doesn't look like opcounts plots would be generated for both PNETCDF and HDF5 if a log happened to have both (probably very rare).

I'm not sure if there's other places in this logic that need fixed. My understanding from the preceding comment is that you only want one of H5F/H5D or PNETCDF_FILE/PNETCDF_VAR, as the H5D and PNETCDF_VAR modules know how to additionally include the file-level data.

I spot checked a couple of summary reports and confirmed tests succeed with the changes, so think I'm content with the changes for now, but could still be some corner cases to sort out.

tylerjereddy · 2022-10-28T00:18:06Z

If you click through the sub-100 % patch diff coverage in CI, those missing lines may be related to your concern above, assuming it isn't a codecov fusing issue.

* PnetCDF module and HDF5 module could conceivably be included in the same report

include/darshan-log-format.h

shanedsnyder · 2022-10-28T19:44:45Z

@carns @wkliao I think I'm all done here, if there are any things you guys wanted to double check before merging. I know it's probably not practical to look through everything, but I'll wait for a thumbs up from you guys before moving ahead.

wkliao · 2022-10-28T19:59:43Z

It will be great to see this PR merged soon.
I plan to use this feature to check WRF I/O pattern.
@shanedsnyder , @tylerjereddy Thanks for your great effort !

carns · 2022-10-29T14:44:05Z

@wkliao @shanedsnyder is it possible to silence some of the warnings that pop out with -Wall? I'm seeing a large volume of warnings like the following with gcc 12.2:

./darshan-pnetcdf-api.c:2524:17: warning: unused variable ‘i’ [-Wunused-variable]
 2524 |             int i, j;
      |                 ^
./darshan-pnetcdf-api.c:2507:9: warning: unused variable ‘err’ [-Wunused-variable]
 2507 |     int err, ret;
      |         ^~~
./darshan-pnetcdf-api.c: In function ‘__wrap_ncmpi_get_var_schar_all’:
./darshan-pnetcdf-api.c:2586:20: warning: unused variable ‘j’ [-Wunused-variable]
 2586 |             int i, j;
      |                    ^

I don't believe these are important; I suspect that it's just an artifact of how the m4 generated code is used for various wrappers. It does make the build output noisy, though, so it could obfuscate meaningful warnings.

I don't know what the options are for this situation; is there something simple like a gcc pragma maybe?

carns

Looks good to me. If there is a way to make the -Wall warnings quieter that would be great, but I approve regardless. Everything runs fine for me. It's need to see the file:variable notation in the record name fields for the VAR module.

wkliao · 2022-10-29T17:35:23Z

Those variables are probably used before, not longer.
They have been removed in 09fe016

carns · 2022-10-30T14:50:13Z

Those variables are probably used before, not longer. They have been removed in 09fe016

Great, thanks @wkliao ! I confirmed that everything compiles cleanly for me now. PR looks good to go to me.

shanedsnyder force-pushed the pnetcdf branch from f935a38 to f1953f5 Compare August 17, 2022 21:35

shanedsnyder requested changes Aug 17, 2022

View reviewed changes

darshan-runtime/doc/darshan-runtime.txt Outdated Show resolved Hide resolved

include/darshan-pnetcdf-log-format.h Outdated Show resolved Hide resolved

shanedsnyder reviewed Aug 24, 2022

View reviewed changes

shanedsnyder added 2 commits October 25, 2022 19:30

add var counter to flag record variables

e0a64c2

- this allows Darshan to capture whether variables are record variables or not

updated pydarshan cffi code for recent changes

8701494

shanedsnyder force-pushed the pnetcdf branch from d5ab04f to 8701494 Compare October 26, 2022 00:36

github-actions bot removed the CI continuous integration label Oct 26, 2022

shanedsnyder added 4 commits October 26, 2022 18:24

add backwards compatibility code for pnetcdf

8702d4c

* allows minimal PnetCDF data captured in prior versions of Darshan to be upconverted to new module formats so it can be parsed by users

updated pydarshan tests, added log for new format

077454e

fixup darshan-util unit tests for pnetcdf changes

427b8cb

remove debugging print in pydarshan test

eb4a3ab

shanedsnyder reviewed Oct 27, 2022

View reviewed changes

bug fix in wait time calculation

a1502ff

shanedsnyder added 5 commits October 28, 2022 07:41

fix if/elif bug in job summary code

460e0c2

* PnetCDF module and HDF5 module could conceivably be included in the same report

PyDarshan I/O histograms only apply to PNETCDF_VAR

4563927

bug fix in pnetcdf module upconvert byteswap

5f08f60

get docs/comments in sync with final changes

e88d4e2

small code cleanup

a19990c

shanedsnyder previously approved these changes Oct 28, 2022

View reviewed changes

carns reviewed Oct 28, 2022

View reviewed changes

include/darshan-log-format.h Show resolved Hide resolved

carns previously approved these changes Oct 29, 2022

View reviewed changes

remove unused variables

09fe016

wkliao dismissed stale reviews from carns and shanedsnyder via 09fe016 October 29, 2022 17:20

shanedsnyder approved these changes Nov 8, 2022

View reviewed changes

shanedsnyder merged commit aef584b into darshan-hpc:main Nov 8, 2022

PnetCDF module #456

PnetCDF module #456

Conversation

wkliao commented Aug 24, 2021

shanedsnyder commented Jul 6, 2022

shanedsnyder commented Aug 17, 2022

shanedsnyder commented Aug 17, 2022

wkliao commented Aug 18, 2022

wkliao commented Aug 18, 2022

wkliao commented Aug 18, 2022

carns commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

wkliao commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

carns commented Aug 18, 2022

carns commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

wkliao commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

shanedsnyder commented Aug 18, 2022

wkliao commented Aug 18, 2022

shanedsnyder commented Aug 19, 2022

shanedsnyder commented Aug 23, 2022

wkliao commented Aug 23, 2022

shanedsnyder commented Aug 23, 2022

wkliao commented Aug 23, 2022

shanedsnyder commented Aug 24, 2022

shanedsnyder commented Aug 24, 2022

shanedsnyder commented Aug 24, 2022 • edited Loading

shanedsnyder Oct 27, 2022

Choose a reason for hiding this comment

shanedsnyder Oct 28, 2022

Choose a reason for hiding this comment

shanedsnyder Oct 27, 2022 • edited Loading

Choose a reason for hiding this comment

tylerjereddy Oct 28, 2022

Choose a reason for hiding this comment

shanedsnyder Oct 28, 2022 • edited Loading

Choose a reason for hiding this comment

tylerjereddy commented Oct 28, 2022

shanedsnyder commented Oct 28, 2022

wkliao commented Oct 28, 2022

carns commented Oct 29, 2022

carns left a comment

Choose a reason for hiding this comment

wkliao commented Oct 29, 2022

carns commented Oct 30, 2022

shanedsnyder commented Aug 24, 2022 •

edited

Loading

shanedsnyder Oct 27, 2022 •

edited

Loading

shanedsnyder Oct 28, 2022 •

edited

Loading