openPMD Plugin #2966

franzpoeschel · 2019-05-20T09:08:51Z

Implement writing to and reading from openPMD.
Todo

The plugin is based very closely on the existing ADIOS plugin and carries some baggage. Especially the strict separation of (1) declaration of datasets (ADIOS variables) and (2) writing data to them is unnecessary from openPMD's point of view and ought to be removed.
openPMD does not allow to create datasets that have zero extent in any dimension. This is what happens for example in the WarmCopper example. Fix that.
The existing HDF5 and ADIOS plugins use different strategies for data preparation. This plugin currently uses the strategy applied in the ADIOS plugin, but both should be supported in the end.
Further testing, especially (1) reading (e.g. restarting) and (2) using openPMD backends other than ADIOS(1|2), i.e. HDF5.
Either wait for this PR in the openPMD API or revert commit 51d55c9.
The plugin needs this commit (PR #511) to compile without error. This should be considered before pulling.

For testing purposes, please use this branch of the openPMD API.

Wait for JSON configuration to land in openPMD API.
Documentation

As noted below, the HDF5 backend in the openPMD API is currently broken and may not be used in this plugin at the moment.

Investigate a workaround for that. EDIT: HDF5 backend has been patched and can now be used from within openPMD plugin.

The resulting storage files are incompatible with the files written by the existing plugins: The existing plugin writes datasets /data/<iteration>/picongpu/idProvider/startID, but the openPMD API only supports writing datasets /data/<iteration>/(fields|particles)/*/*(/*) at the moment, so those datasets have been temporarily relocated to /data/0/fields/picongpu_idProvider/startId until the openPMD allows to write "heavy" metadata more flexibly.

I've written up a simple guide for building and installing.

wait for results from @steindev's runtime tests

share/picongpu/examples/FoilLCT/etc/picongpu/5.cfg

ax3l · 2019-05-20T11:59:14Z

include/picongpu/versionFormat.cpp

+                << OPENPMDAPI_VERSION_MINOR
+                << "."
+                << OPENPMDAPI_VERSION_PATCH
+                << " ("


note: OPENPMDAPI_VERSION_LABEL might be empty and should only be added if it's a non-empty string.
Examples:

0.6.2-alpha

1.2.3-rc1

1.2.3

(see how we build the PIConGPU version string for comparison)

I changed that part, but is the value actually used anywhere? Everywhere throughout the codebase where getSoftwareVersions( std::ostream & cliText ) is called, the return value is discarded. Only the writes to cliText have an effect, really.

It's still a bit off: it must be -label in semver (see example in first comment).

The idea is to include this in openPMD meta info at some point openPMD/openPMD-standard#137 as well as picongpu --version

@franzpoeschel you can now use the new public API to build your version strings:
https://github.com/openPMD/openPMD-api/blob/0.11.0-alpha/include/openPMD/version.hpp#L54-L80

I've changed it to use that now

include/picongpu/CMakeLists.txt

include/picongpu/plugins/openPMD/restart/RestartFieldLoader.hpp

include/picongpu/plugins/openPMD/openPMDWriter.def

include/include.svg

include/picongpu/CMakeLists.txt

include/picongpu/plugins/openPMD/WriteMeta.hpp

include/picongpu/plugins/openPMD/WriteSpecies.hpp

include/picongpu/plugins/openPMD/writer/ParticleAttribute.hpp

ax3l · 2019-06-07T12:41:33Z

CI says:

$ test/hasEOLwhiteSpace
./include/picongpu/plugins/openPMD/openPMDWriter.hpp contains EOL white spaces!
./include/picongpu/versionFormat.cpp contains EOL white spaces!
SUMMARY
-------
Run the following command(s) on the above files to remove your
end-of-line (EOL) white spaces:
sed -i 's/[[:blank:]]\+$//' ./include/picongpu/plugins/openPMD/openPMDWriter.hpp
sed -i 's/[[:blank:]]\+$//' ./include/picongpu/versionFormat.cpp

ax3l · 2019-06-07T12:57:21Z

share/picongpu/examples/KelvinHelmholtz/etc/picongpu/4.cfg

@@ -54,7 +54,7 @@ TBG_ipngYX="--i_png.period 10 --i_png.axis yx --i_png.slicePoint 0.5 --i_png.fol
 TBG_eBin="--e_energyHistogram.period 100 --e_energyHistogram.filter all --e_energyHistogram.binCount 1024 --e_energyHistogram.minEnergy 0 --e_energyHistogram.maxEnergy 5000"
 TBG_iBin="--i_energyHistogram.period 100 --i_energyHistogram.filter all --i_energyHistogram.binCount 1024 --i_energyHistogram.minEnergy 0 --i_energyHistogram.maxEnergy 2000000"

-TBG_plugins="!TBG_ipngYX                   \
+TBG_plugins="--openPMD.period 1000 --openPMD.file simData%T.bp !TBG_ipngYX                   \


I think we prefer an underscore separation and zero-prefixed: simData_%06T.bp

!TBG_ipngYX should be on the next line

I need to keep an eye on which files I commit, those were supposed to stay local for now.
Should I revert them back to the older versions or should I change them to use the new openPMD plugin? At the moment, this PR does not change the default writing plugin which is still ADIOS.

share/picongpu/examples/LaserWakefield/etc/picongpu/4.cfg

share/picongpu/examples/WarmCopper/etc/picongpu/1.cfg

share/picongpu/examples/WeibelTransverse/etc/picongpu/4.cfg

ax3l · 2019-06-07T13:00:31Z

include/picongpu/versionFormat.cpp

+                << OPENPMDAPI_VERSION_MINOR
+                << "."
+                << OPENPMDAPI_VERSION_PATCH
+                << " ("


It's still a bit off: it must be -label in semver (see example in first comment).

The idea is to include this in openPMD meta info at some point openPMD/openPMD-standard#137 as well as picongpu --version

share/picongpu/examples/Bunch/etc/picongpu/32.cfg

share/picongpu/examples/Empty/etc/picongpu/1.cfg

share/picongpu/examples/FoilLCT/etc/picongpu/4.cfg

share/picongpu/examples/SingleParticleTest/etc/picongpu/1.cfg

franzpoeschel · 2019-06-13T14:05:01Z

EDIT: is resolved
Due to a bug in the HDF5 backend of the openPMD API, the plugin can currently not be used together with openPMD's HDF5 backend.

If a user is absolutely destined to use HDF5 backend until this bug is resolved, the following temporary patch to the openPMD API is suggested: In HDF5IOHandler.cpp, replace

    file_id = H5Fopen(name.c_str(),
                      flags,
                      m_fileAccessProperty);
    if( file_id < 0 )
        throw no_such_file_error("Failed to open HDF5 file " + name);

with

    file_id = H5Fopen(name.c_str(),
                      flags,
                      m_fileAccessProperty);
    if( file_id < 0 )
        file_id = *m_openFileIDs.begin();

This workaround assumes that an error -- if one occurs while opening a file -- is due to the mentioned issue in the openPMD API and then uses the fact that in the openPMD plugin only deals with one file at a time to retrieve the file handle from m_openFileIDs.

franzpoeschel · 2019-06-21T09:37:49Z

The latest commit (51d55c9) requires this PR in the openPMD API.

sbastrakov · 2019-06-27T15:13:00Z

include/picongpu/plugins/openPMD/openPMDWriter.hpp

+                                 .productOfComponents();
+            if( size > 0 )
+                mThreadParams.fieldBuffer = std::shared_ptr< float_X >{
+                    new float_X[ size ],


Forgot to ask during your talk: is there an issue with using std::vector instead of C-style array? (and potentially .data() to get a raw pointer to its elements).

This should be no problem. The openPMD API explicitly allows to use contiguous containers and implements this by mocking a shared pointer via .data().
Would using a std::vector be preferrable?

I like std::vector a little bit more. Of course, in this case, it is not such a big deal since even with the raw pointers you take care that it is properly deleted.

Yep, always prefer smart-ptrs and contiguous containers (std::vector/std::array) over C-style arrays.
openPMD-api supports std::array and std::vector out-of-the-box for that purpose, as Franz already mentioned :) Here he is using a smart-ptr, which is totally fine as well for temporary memory.
https://github.com/openPMD/openPMD-api/blob/dev/include/openPMD/auxiliary/ShareRaw.hpp
openPMD/openPMD-api#386
https://openpmd-api.readthedocs.io/en/0.9.0-alpha/usage/firstwrite.html#register-chunk

std::shared_ptr is the implementation detail below, works here as well if you do not want to keep track when to de-allocate it. Actually also a good usage here, if you want to use mThreadParams.fieldBuffer only until registered for write/read and be done at flush with it. Otherwise its your responsibility when to destruct the container to free its memory.

As mentioned further down the thread, I've moved it to std::vector due to easier resizing.

JunCEEE · 2019-09-13T14:30:37Z

Just one more comment on Franz's note:

The resulting storage files are incompatible with the files written by the existing plugins: The existing plugin writes datasets /data//picongpu/idProvider/startID, but the openPMD API only supports writing datasets /data//(fields|particles)//(/*) at the moment, so those datasets have been temporarily relocated to /data/0/fields/picongpu_idProvider/startId until the openPMD allows to write "heavy" metadata more flexibly.

Right now, I'm working on the Molecular Dynamics Simulation domain extension of openPMD standard for start-to-end simulation platform. We also met a similar problem. Our preferred style is the Data structure extended example described here. However, the observables and box cannot be added by openPMD-api due to the same reason as that of Franz. This "heavy" metadata support might be more needed when more standard extensions are going to be defined.

ax3l · 2019-09-13T17:04:54Z

Yes, @franzpoeschel (or volunteers forward :) ) please add this functionality to openPMD-api and also open an issue therein. We need a simple low-level API that can just add attributes and records arbitrarily along the "in-file three". That was originally a task when Fabian was still working on this but did not get finished yet.

That said: one can totally implement openPMD, including new extensions, without openPMD-api in the meantime for @ejcjason :) But ideally I want to have this in the API of course, because it makes it easier to adopt.

psychocoderHPC · 2020-05-06T06:03:52Z

include/picongpu/plugins/openPMD/openPMDWriter.hpp

+            }
+
+            /* copy species only one time per timestep to the host */
+            if( ( mThreadParams.strategy == WriteSpeciesStrategy::ADIOS ) &&


parentheses are not required: should be if( mThreadParams.strategy == WriteSpeciesStrategy::ADIOS && lastSpeciesSyncStep != currentStep )`

I like to be explicit with parens, but this was maybe a bit very explicit. Removed them.

psychocoderHPC

@franzpoeschel Could you please squash the commit. Never the less from my side all looks good. (only one thing with too much parentheses but it is not critical)

franzpoeschel · 2020-05-06T10:12:54Z

Results of running the openPMD validator on the checkpoint files:

> openPMD_check_h5 -i checkpoints/checkpoint_000000.h5 
Warning: Attribute author (recommended) does NOT exist in `/`!
Found 1 iteration(s)
Iteration 0 : found 3 meshes
Iteration 0 : found 1 particle species
Warning: Key particlePatches (recommended) does NOT exist in `/data/0/particles/e`!
Error: Attribute timeOffset in `/data/0/particles/e/momentum` is not of type '<map object at 0x7f1716a3f748>' (is 'float32')!
Error: Attribute timeOffset in `/data/0/particles/e/particles_info` is not of type '<map object at 0x7f1716a3f9e8>' (is 'float32')!
Error: Attribute timeOffset in `/data/0/particles/e/position` is not of type '<map object at 0x7f1716a3f978>' (is 'float32')!
Error: Attribute timeOffset in `/data/0/particles/e/positionOffset` is not of type '<map object at 0x7f1716a3f748>' (is 'float32')!
Error: Attribute timeOffset in `/data/0/particles/e/weighting` is not of type '<map object at 0x7f1716a3f828>' (is 'float32')!
Result: 5 Errors and 2 Warnings.

The validator consistently complains about timeOffset which seems to me is rather a bug in the validator. These attributes are single scalar float values with value 0.f just like in the ADIOS backend which is the default set by the openPMD API.

The only difference for this attribute between the valid example dataset created by openPMD_createExamples_h5 and the checkpoint file is the floating point precision:

> h5ls -rv checkpoint_000000.h5
[...]
/data/0/particles/e/weighting Dataset {27262976/27262976}
    Attribute: timeOffset scalar
        Type:      native float
        Data:  0
[...]
> openPMD_createExamples_h5
> h5ls -rv example.h5
[...]
/data/0/particles/electrons/weighting Dataset {128/128}
    Attribute: timeOffset scalar
        Type:      native double
        Data:  0
[...]

EDIT: I quickly patched the openPMD API for testing purposes to write double-precision floating points instead of single precision, the validator likes this more:

> h5ls -rv checkpoints/checkpoint_000000.h5
[...]
/data/0/particles/e/weighting Dataset {27262976/27262976}
    Attribute: timeOffset scalar
        Type:      native double
        Data:  0
[...]
> openPMD_check_h5 -i checkpoints/checkpoint_000000.h5 
Warning: Attribute author (recommended) does NOT exist in `/`!
Found 1 iteration(s)
Iteration 0 : found 3 meshes
Iteration 0 : found 1 particle species
Warning: Key particlePatches (recommended) does NOT exist in `/data/0/particles/e`!
Result: 0 Errors and 2 Warnings.

The validator shouldn't consider single precision an error 1, 2.

franzpoeschel · 2020-05-06T10:37:12Z

Concerning the two warnings:

author: Is implemented, but only written if an author is accessible via Environment<>::get().SimulationDescription().getAuthor( ) which I didn't set for this test.
Particle patches: these are only written by the HDF5 plugin so far, not by the ADIOS plugin which I based this plugin on. I would suggest keeping this for a later PR?

psychocoderHPC · 2020-05-06T11:08:43Z

Particle patches: these are only written by the HDF5 plugin so far, not by the ADIOS plugin which I based this plugin on. I would suggest keeping this for a later PR?

Without particle patches a restart with PIConGPU should not be possible.
Is it hard to copy over the particle patches from the HDF5 plugin.

sbastrakov · 2020-05-06T11:10:15Z

@franzpoeschel regarding the author. If I got it right, we normally set it automatically via your picongpu profile variable, like this, and then tbg substitutes it for all picongpu runs.

franzpoeschel · 2020-05-06T12:01:27Z

Particle patches: these are only written by the HDF5 plugin so far, not by the ADIOS plugin which I based this plugin on. I would suggest keeping this for a later PR?

Without particle patches a restart with PIConGPU should not be possible.
Is it hard to copy over the particle patches from the HDF5 plugin.

But the ADIOS plugin currently does restarts without particlePatches? I will look into it tomorrow.

@franzpoeschel regarding the author. If I got it right, we normally set it automatically via your picongpu profile variable, like this, and then tbg substitutes it for all picongpu runs.

I was launching PIConGPU bare-bones without tbg. I ran another test, this time setting --author and the warning is no longer present.

steindev · 2020-05-06T12:33:23Z

Particle patches: these are only written by the HDF5 plugin so far, not by the ADIOS plugin which I based this plugin on. I would suggest keeping this for a later PR?

Without particle patches a restart with PIConGPU should not be possible.
Is it hard to copy over the particle patches from the HDF5 plugin.

But the ADIOS plugin currently does restarts without particlePatches? I will look into it tomorrow.

Restarts definitely work! This was one of the main concerns and one reason for performing the test I did. Thus the question: Is it really necessary to have these? If not, I don't see a reason to invest more time in this already working backend.

psychocoderHPC · 2020-05-06T17:39:52Z

If it work we should merge it as it is and add it in a separate PR. Am 6. Mai 2020 14:33:39 MESZ schrieb Klaus Steiniger <notifications@github.com>:

…

> > > * Particle patches: these are only written by the HDF5 plugin so far, not by the ADIOS plugin which I based this plugin on. I would suggest keeping this for a later PR? > > > > > > Without particle patches a restart with PIConGPU should not be possible. > > Is it hard to copy over the particle patches from the HDF5 plugin. > > But the ADIOS plugin currently does restarts without particlePatches? I will look into it tomorrow. Restarts definitely work! This was one the main concerns and one reason for performing the test I did. Thus the question: Is it really necessary to have these? If not, I don't see a reason to invest more time in this already working backend. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2966 (comment)

franzpoeschel · 2020-05-18T13:44:47Z

Last commit c54bbab adds writing of particle patches. These are not yet used for restarting, but instead the plugin uses the particle_info table. Will remove that next up.

franzpoeschel · 2020-05-18T18:37:03Z

The last two commits 2135fb6 and e0e9d9f remove the particles_info table in favor of particlePatches. The errors after restarting remain in the same orders of magnitude:

max rel. error: 2.3449754e-06 mean error: 5.117661e-08 median error: 0.0 std rel. error: 7.151421e-08

Create openPMDWriter based on ADIOSWriter (WIP) Adapt CountParticles partially to openPMD Adapt WriteSpecies to openPMD Translate WriteMeta.hpp to openPMD Add function "asStandardVector()" Translate NDScalars.hpp to openPMD Adapt everything to openPMD except for the main file (openPMDWriter.hpp) Adapt openPMDWriter.hpp to openPMD WIP Change management of openPMD Series Further adapt openPMDWriter to openPMD Add openPMD to CMake Add openPMD to version formatting Properly acquaint openPMD plugin with build and help system Make openPMD namespacing explicit Remove adios-specific fields from ThreadParams First successfull run with LaserWakeField example Cleanup Use clang-format Update licensing information Separate basename and filename extension into two separate help parameters Refactor dataset creation Use Mesh::setTimeOffset() template Causes a linker error with the current version of openPMD API, a fix will be merged soon on the dev branch. Clean up some leftovers Use ASCII characters to spell my name Remove unnecessary whitespaces Adapt to removal of pmacc::forward Remove accidentally versioned config file Make checkpoints usable Fix a number of bugs concerning the reading of checkpoints Still problematic is the attribute "timeOffset", currently mitigated by uncommenting the sanity check in the openPMD API. Needs further investigation. Remove CollectFieldsSizes Legacy from ADIOS writer, not necessary in openPMD. Remove ParticleAttributeSize and openPMDCountParticles Legacy from ADIOS Writer Use clang-format Adhere to openPMD requirements before flushing For a given particle species, the openPMD API requires that required records (such as "position", "positionOffset") and their contained components be defined (not necessarily written). Make sure to define all such datasets before issuing the first flush. Maybe open an issue in the openPMD API to allow for a more flexible usage. Fix an indexing bug Eliminate dataset preparation for NDScalars Also fix a bug where particles were named wrongly in checkpoints. Do not write empty particle datasets Treat non-existing datasets as empty in reading Remove prepared datasets Remove WithWindow struct Use transform to enable ADIOS1 compression Remove accidentally versioned files Rename LoadParticleAttributesFromADIOS to LoadParticleAttributesFromOpenPMD Remove traces of the old ADIOS plugin mostly the word "adios" from comments Take copies and not references of openPMD handles Fix autoformatting Require newer openPMD API Also add ADIOS2_ROOT to CMAKE_PREFIX_PATH Add version label to format string only if present Replace typedefs with using Remove further indexing bug in writing particles_info table Cleanup restart Remove dataset preparation Commit 0b50561 reintroduced a reduced form of dataset preparation in order to adhere to requirements (restrictions) of the openPMD API. This workaround results in dummy dataset writes (likely a bug in the openPMD API), hence this commit reverts those changes. The corresponding pull request in the openPMD API to relax this restriction can be found at openPMD/openPMD-api#518. Postpone writing of meta attributes Due to a bug in the ADIOS1 backend of the openPMD API, the first dataset needs to be written before the first flush. This works around the problem by first defining all the fields and particles. Bug report will follow. Resolve counting bug during particle writing Fix whitespaces Separate ADIOS and HDF5 particle writing strategies Allow choosing strategy as runtime parameter Cleanup Fix openPMD version formatting Update examples to use openPMD Refactor passing of filename and extension Reassemble filename and extension upon opening the series. Fix some missing includes Do not skip writing empty datasets See openPMD PR: openPMD/openPMD-api#529 This allows to write empty datasets Remove debugging leftovers Write timeOffset for particles in a standard-compliant way Do not declare zero-sized arrays C++ standard requires that array size evaluate to a value greater than zero. Do not use storeChunk on empty datasets centralize initialization of thread params from config Fix undefined identifier in assert statements Error passes silently in release builds. Pass JSON config to openPMD::Series ctor Do not copy Series object see openPMD/openPMD-api#534 Allow NULL as configuration infix to denote empty string Adapt to changes in pmacc etc. Enable use of group-based layout as well Requires keeping openPMD Series open. Since openPMD currently has no explicit call to close a file, we implement this only for group-based layout for now. Do not use deprecated Series::setSoftwareVersion call Apply commit b797c0a to openPMD backend Formatting in .cfg files Fix an uninitialized value and an indexing bug Implement reviewers' comments concerning CMakeLists Fix some bugs and remove unneeded parameters Some ADIOS-specific parameters have been remove that haven't been implemented anyway and are going to be implemented via JSON. Don't set compression if set to "none". Also, I missed a small part when porting b797c0a to this plugin. Add documentation for openPMD plugin [WIP] Further write documentation Rename data preparation strategies adios -> doubleBuffer hdf5 -> mappedMemory Old names may still be used alternatively. Fix indexing bug for non domain-bound fields Fix indexing order in fields Implement Reviewer's comments Remove workaround for ADIOS1 backend fix attributes Mesh record component positions and unitSI Iteration: time ParticleAttribute unitDimension Implement reviewer's comments (2) Update copyright headers of files changed Add compression to openPMD TBG example Use openPMD::getVersion remove unnecessary parentheses

@todo

Not yet used for restarting, instead the custom 'particles_info' table is used. @todo Remove that in future

ax3l · 2020-05-18T21:08:19Z

I think we should add an Iteration::close() method to openPMD-api relatively soon, because otherwise already flushed files cannot be opened for post-processing until the overall sim has finished (handles stay open).

franzpoeschel · 2020-05-18T23:12:03Z

Agreed, will get to that next.
Just FYI, the plugin currently distinguishes file-based from group-based iteration layout and will reopen and close the Series each iteration in file-based layout as a workaround. Otherwise, most filesystems wouldn't let me handle any more file handles after some iterations in a sufficiently parallel simulation, crashing the simulation.

ax3l · 2020-05-18T23:24:53Z

Sounds good, so on top of the ::close() we should probably add a max-filehandles option that closes open files, beginning with the longest unused handle. I remember we did that in libSplash for the same reasons, too.

psychocoderHPC · 2020-06-23T11:13:52Z

@franzpoeschel I thought we merged the OpenPMD plugin already. Is everything ready to merge?

franzpoeschel · 2020-06-23T15:13:53Z

Ah, I thought we were still waiting for the next openPMD release.
For now, I'm finished, yes. Once the PR that allows closing files early lands in the openPMD API, I can remove this workaround, but I that can also be done in a follow-up PR.

(Also, I missed the this PR's 1-year anniversary last month :D )

psychocoderHPC · 2020-06-24T09:19:36Z

OK than I will merge it and we will do all future work in a follow up.

psychocoderHPC self-requested a review May 20, 2019 11:09

psychocoderHPC changed the title ~~WIP openPMD Plugin~~ [WIP] openPMD Plugin May 20, 2019

psychocoderHPC added component: plugin in PIConGPU plugin refactoring code change to improve performance or to unify a concept but does not change public API labels May 20, 2019

psychocoderHPC added this to the 0.5.0 / 1.0.0: Next Stable milestone May 20, 2019

ax3l self-requested a review May 20, 2019 11:54

ax3l assigned ax3l and psychocoderHPC May 20, 2019

ax3l reviewed May 20, 2019

View reviewed changes

franzpoeschel force-pushed the topic-openpmd-backend branch 2 times, most recently from 56ff067 to 02eef50 Compare May 23, 2019 08:51

ax3l reviewed May 28, 2019

View reviewed changes

franzpoeschel force-pushed the topic-openpmd-backend branch 2 times, most recently from 0e0c177 to b756abc Compare May 28, 2019 14:59

franzpoeschel mentioned this pull request Jun 5, 2019

Allow flushing before defining position and positionOffset components of particle species openPMD/openPMD-api#518

Merged

ax3l reviewed Jun 7, 2019

View reviewed changes

franzpoeschel force-pushed the topic-openpmd-backend branch from 3b3dd63 to 5ed5342 Compare June 13, 2019 15:06

franzpoeschel mentioned this pull request Jun 13, 2019

HDF5 backend – reopening file that is already open openPMD/openPMD-api#524

Closed

franzpoeschel force-pushed the topic-openpmd-backend branch 3 times, most recently from 813c00e to 157ac20 Compare June 19, 2019 11:32

sbastrakov reviewed Jun 27, 2019

View reviewed changes

franzpoeschel force-pushed the topic-openpmd-backend branch from a837a14 to 0252c00 Compare July 3, 2019 14:16

ax3l mentioned this pull request Aug 23, 2019

[WIP] Jupyter widgets: automatic update of plot options #2911

Closed

JunCEEE mentioned this pull request Sep 13, 2019

Allow 2D/nested list in iteration.set_attribute function openPMD/openPMD-api#561

Closed

psychocoderHPC reviewed May 6, 2020

View reviewed changes

psychocoderHPC previously approved these changes May 6, 2020

View reviewed changes

franzpoeschel dismissed psychocoderHPC’s stale review via b6a783e May 6, 2020 08:49

franzpoeschel force-pushed the topic-openpmd-backend branch from f140eee to b6a783e Compare May 6, 2020 08:49

franzpoeschel added 4 commits May 18, 2020 21:12

Write Particle Patches

c54bbab

Not yet used for restarting, instead the custom 'particles_info' table is used. @todo Remove that in future

Remove writing of particles_info table

e0e9d9f

Load from particle Patches

2135fb6

franzpoeschel force-pushed the topic-openpmd-backend branch from 37a5fb1 to 2135fb6 Compare May 18, 2020 19:12

psychocoderHPC approved these changes Jun 24, 2020

View reviewed changes

psychocoderHPC merged commit 3b020b3 into ComputationalRadiationPhysics:dev Jun 24, 2020

This was referenced Jun 24, 2020

update hemera modules and add openPMDapi module #3270

Merged

fix openPMD plugin doc #3271

Merged

PrometheusPi mentioned this pull request Aug 31, 2020

openPMD plugin running with gcc@9.3.0 #3337

Closed

franzpoeschel mentioned this pull request Sep 3, 2021

openPMD plugin: no hardcoding of float_X in writeField() #3759

Merged

2 tasks

openPMD Plugin #2966

openPMD Plugin #2966

Conversation

franzpoeschel commented May 20, 2019 • edited by psychocoderHPC Loading

ax3l May 20, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ax3l commented Jun 7, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

franzpoeschel commented Jun 13, 2019 • edited Loading

franzpoeschel commented Jun 21, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ax3l Aug 20, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JunCEEE commented Sep 13, 2019

ax3l commented Sep 13, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

psychocoderHPC left a comment

Choose a reason for hiding this comment

franzpoeschel commented May 6, 2020 • edited Loading

franzpoeschel commented May 6, 2020

psychocoderHPC commented May 6, 2020

sbastrakov commented May 6, 2020

franzpoeschel commented May 6, 2020

steindev commented May 6, 2020 • edited Loading

psychocoderHPC commented May 6, 2020 via email

franzpoeschel commented May 18, 2020 • edited Loading

franzpoeschel commented May 18, 2020 • edited Loading

ax3l commented May 18, 2020

franzpoeschel commented May 18, 2020

ax3l commented May 18, 2020 • edited Loading

psychocoderHPC commented Jun 23, 2020

franzpoeschel commented Jun 23, 2020

psychocoderHPC commented Jun 24, 2020

franzpoeschel commented May 20, 2019 •

edited by psychocoderHPC

Loading

ax3l May 20, 2019 •

edited

Loading

franzpoeschel commented Jun 13, 2019 •

edited

Loading

ax3l Aug 20, 2019 •

edited

Loading

ax3l commented Sep 13, 2019 •

edited

Loading

franzpoeschel commented May 6, 2020 •

edited

Loading

steindev commented May 6, 2020 •

edited

Loading

franzpoeschel commented May 18, 2020 •

edited

Loading

franzpoeschel commented May 18, 2020 •

edited

Loading

ax3l commented May 18, 2020 •

edited

Loading