Modern setup.py: CMake-Driven, Multi-Dimensional #1647

ax3l · 2021-01-22T19:19:54Z

This adds a new, project-centric setup.py file. With this file, all dimensions (2D, 3D, RZ) of WarpX can be built and packaged at once, using the CMake build logic.

Build & install:

python3 -m pip wheel -v .
python3 -m pip install *whl

Via a source package:

python setup.py sdist --dist-dir .
pip wheel -v pywarpx-21.01.tar.gz
python3 -m pip install *whl

or directly with install:

python setup.py sdist --dist-dir .
pip install -v pywarpx-21.01.tar.gz

To Do

add requirements.txt and pyproject.toml
write docs
test source package
test:

docker run -it -v ${PWD}:/warpx ubuntu:latest

apt update
apt upgrade

apt install -y build-essential cmake git libadios-dev libhdf5-dev python3-setuptools python3-pip python3-wheel
# apt install -y libopenmpi-dev libadios-openmpi-dev libhdf5-openmpi-dev
python3 -m pip install -U pip

WarpX_OPENPMD=ON python3 -m pip wheel -v .
python3 -m pip install *whl

run a serial PICMI setup

Future

potentially remove unused copies of "long-name" library names (cosmetic)

requirements.txt

dpgrote · 2021-01-22T19:43:04Z

setup.py

+# Work-around for https://github.com/pypa/setuptools/issues/1712
+# note: changed default for SHARED, MPI, TESTING and EXAMPLES
+WarpX_COMPUTE = os.environ.get('WarpX_COMPUTE', 'OMP')
+WarpX_MPI = os.environ.get('WarpX_MPI', 'OFF')


Is there a reason that MPI is set to off (overriding the default)?

Discussed in VC: we disable dependencies that error out and fail the build. We will document how to build against MPI (also needs to disable binaries for transient dependencies like mpi4py).

setup.py

ax3l · 2021-01-25T20:12:52Z

requirements.txt

+numpy~=1.15.0
+periodictable~=1.5.3
+picmistandard==0.0.13
+scipy~=1.6.0  # picmistandard bug: https://github.com/picmi-standard/picmi/pull/34


PR open in: picmi-standard/picmi#34

does not hurt to keep this here until the next release of picmistandard is out

Docs/source/building/cmake.rst

This adds a new, project-centric setup.py file. With this file, all dimensions (2D, 3D, RZ) of WarpX can be built and packaged at once, using the CMake build logic. Build & install: ```bash pip wheel -v . pip install *whl ```

dpgrote · 2021-01-27T00:12:52Z

setup.py

+    cmdclass=dict(build_ext=CMakeBuild),
+    # scripts=['warpx_2d', 'warpx_3d', 'warpx_rz'],
+    zip_safe=False,
+    python_requires='>=3.6, <3.10',


Why specify '<3.10'?

I usually do this because I want to test a new python release and then push a new package release that supports it first. This way users get a clean message that we have not yet released a Python 3.10 package that we know is good.

It's probably not needed here though (yet), but I know that e.g. middleware like pybind11 needs to be tested against a new CPython usually first. And then we want to build new wheels for a new Python release, too.

So I have no strong objection to keeping the upper range open, yet practically we release 1x a month and that's quick enough until users can upgrade (and there are many python version to fall back to).

I thought that you might have had a specific reason to exclude 3.10 (like you knew about some upcoming API change that would break things).

I would be less conservative (and leave out the <3.10) but don't have a strong preference. Either way you'll get complaints from users, that 3.10 causes problems, or that 3.10 is not supported (even though it might work fine).

From experience, I know that CPython 3.8 had a performance change in memory buffers and CPython 3.9.0 had a memory error on macOS. Both of them were with pybind11 visible through openPMD-api, so I just kept the workflow :)

Either way you'll get complaints from users, that 3.10 causes problems, or that 3.10 is not supported (even though it might work fine).

Just some subjective thoughts here on my experience with openPMD-api shippings:

True, but users that use conda-forge, brew, modules or their system python are "slow". For instance, most people even now don't use Python 3.9 yet. If we would be slow in releases (monthly is very fast), package managers like conda-forge would just automatically downgrade their python version and users might not even notice if they build a new WarpX environment that it's not cutting edge.

The users that go very cutting edge on CPython releases are also usually in the category that know how to downgrade and will not be blocked. The broad majority that just gets a breaking default install because a new breaking dependency was released on Saturday evening might be blocked by those - and also adds an urgency to bug reports that is harder to schedule for us maintainers (because they are blocked, need manual advise and we need to move faster) :)

dpgrote · 2021-01-27T00:21:34Z

requirements.txt

@@ -0,0 +1,9 @@
+numpy~=1.15.0


Is there a reason that you use "~=" instead of ">="? The same for periodictable and scipy. (Sorry for the picky comments.)

Sure thing: it's because numpy and scipy use semantic versioning and it's unlikely we will work with a major release and its associated breaks before testing it.

This semantic here says: use numpy>=1.15.0,<2.0.0

Since I want to avoid being ping-ed by users on Slack because they got the two-hour-old numpy release and nothing works anymore, I rather like the pip dependency resolver to load the last 1.* release of numpy for instance and update at our own speed in the next monthly release.
If both works, we just push numpy~=1.15.0,~=2.0.0 in the following release.

It's basically a way to channel releases and support at our own pace instead of being driven by (breaking) third-party releases (and their bugs).

Ok, being conservative about releases is probably not a bad thing. Though it'll probably be a long time before we'll have NumPy version 2.

dpgrote · 2021-01-27T01:03:44Z

.github/workflows/source/hasNonASCII

@@ -28,6 +28,7 @@ for i in $(find . \
                -not -path "*wp_parse*"        \
                -not -path "./tmp_build_dir/*" \
                -not -path "./Docs/*"          \
+                -not -path "./setup.py"        \


I don't see any non-ascii in setup.py - why is it excluded?

I wrote Maxence Thévenet and Rémi Lehe in the author/maintainer strings :)
(The é is not part of ASCII.)

Ah. Their names are written with e in the source code, so maybe be consistent with that rather than have this one exception.

Good point, I just felt fancy because UTF8 works so well in Python :) @RemiLehe @MaxThevenet any preferences? This is the meta-data showing up on PyPI.

For C/C++ code we use ASCII only because some compilers and tools have sadly issues with non-ascii characters. (Just a matter of time until this will also become better.)

dpgrote

Looks good!

…rpX#1624) * Fix bug in momentum-conserving interpolation function * Reset checksum benchmark for CI test momentum-conserving-gather Unused Params: Check after Step 0 (ECP-WarpX#1596) An early check for unused parameters after the first step. Add Superparticle version of getParticlePosition. (ECP-WarpX#1640) * Add Superparticle version of GetParticlePosition. * move unpack_particle to a free function and rename * no longer need SuperPType * Update Source/Particles/Pusher/GetAndSetPosition.H * remove templating from get_particle_position * remove template * Add missing include Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Distribution mapping and cost plotting (ECP-WarpX#1444) * Distribution mapping and cost plotting Cleanup Cleanup Cleanup EOL Unused import * Cost initializes to 0.0 * plot slices of 3D * WIP * WIP docs * docs * docs * docs * docs * docs * docs * docs * docs * EOL SpeciesProperties: C, N, O, Cu (ECP-WarpX#1638) * SpeciesProperties: C, N, O, Cu Add more ionic species as pre-defined particle species. * Cu: Add to Ionization Energies Fix 2D: ParticleHistogram (ECP-WarpX#1635) Fix out-of-bounds access in particle histogram in non-3D. Fix FilterFunctor in non-3D (ECP-WarpX#1633) Fix an out-of-bounds access to positions in 2D & RZ for filter functors. openPMD: ionizationLevel (ECP-WarpX#1622) * openPMD: ionizationLevel Write out the ionizationLevel with openPMD. * openPMD Record Repetitions: Use Lambdas openPMD: Particle Filter (Container) (ECP-WarpX#1632) * openPMD: Particle Filter (Container) A fresh implementation of particle filters for openPMD diagnostics using the generalized `PhysicalParticleContainer` approach that we also use in plotfiles 🎉 * Ion Example: Filter & Coarsen Test diagnostics filter & coarsen functions in CI. Test reduced diagnostics (histograms). Define: _OPENMP -> AMREX_USE_OMP (ECP-WarpX#1520) * Define: _OPENMP -> AMREX_USE_OMP Replace the define check of `_OPENMP` with the explicit backend control of `AMREX_USE_OMP` for parallel constructs. Doing so avoids that we accidentially turn on OpenMP, e.g. if a dependency pulls it in for linear algebra, I/O, etc. This can led to confusion if the user explicitly requested a serial build. Also, we might want to use OpenMP functionality here and there for auxiliary functions w/o having to use the AMReX OpenMP backend, i.e. because we compile for GPUs. * Add missing amrex::Gpu::notInLaunchRegion Start: PerformanceHints After Init (ECP-WarpX#1630) Start a helper routine that gives performance hints after initialization of the simulation. Fix number of guard cells in PML with 2D PSATD (ECP-WarpX#1648) Remove unused lines about particle filters (ECP-WarpX#1646) Add parameter for default galilean velocity (ECP-WarpX#1097) * Add parameter for default galilean velocity * Apply suggestions from code review Co-authored-by: Edoardo Zoni <59625522+EZoni@users.noreply.github.com> * Fix bug in constructor of PhysicalParticleContainer * Use new input parameter in CI test Co-authored-by: Edoardo Zoni <59625522+EZoni@users.noreply.github.com> Co-authored-by: Edoardo Zoni <ezoni@lbl.gov> Cleaned up field diagnostic in picmi interface (ECP-WarpX#1649) Use pinned memory for tmp particles in diags. (ECP-WarpX#1644) * Use pinned memory for tmp particles in diags. * openPMD: pinned memory (tmp particles) Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Replace an always false test with an abort (ECP-WarpX#1655) * replace always false test with abort * fix bug [mini-PR] Broken link to scripts (ECP-WarpX#1651) CI: Ubuntu-latest -> 20.04 (ECP-WarpX#1654) Start Embedded Boundary development (ECP-WarpX#1641) * Start Embedded Boundary development Modify the build system for embedded boundary (EB) support. Currently EB is a compile time option that must be explicitly enabled. For GNU Make, one can enable it with `USE_EB=TRUE`, whereas for CMake, `-DAMReX_EB=ON`. Later we could decide to enable EB by default with all regular geometry. Add a simple geometry initialization function, WarpX::InitEB. By default, the geometry is all regular. A few basic types such as box, cylinder, plane, sphere, etc. are supported via ParmParse runtime parameters. See `amrex/Src/EB/AMReX_EB2.cpp` for more details. Later, we could build more complex geometry using constructive solid geometry (CSG). ( https://en.wikipedia.org/wiki/Constructive_solid_geometry ) See `amrex/Tutorials/EB/GeometryGeneration` for an example of CSG. There is also a STL ( https://en.wikipedia.org/wiki/STL_(file_format) ) approach under development in AMReX. Add a new member, m_factory, to WarpX class. This object can be used to obtain geometry information such as whether a cell is cut, edge centroids, etc. Currently we are not using these factories to build MultiFabs for field data to embed the geometry information into the data containers. We could do that later if it is needed or it makes things more convenient. Nevertheless, this should be sufficient to start the EB development of the field solver. It's not clear to me yet how many ghost cells are needed for the geometry information. It's currently one, and can be adjusted. In the future, when particle and embedded boundary interaction is considered, we can use `amrex::FillSignedDistance` function to obtain signed distance function on the nodes. With that information, one should be able to determine where and when a particle collides with the embedded boundary. * resize factory vector * CMake: Require AMReX_EB for embedded boundaries * Add AMReX_Config.H et al. Explicit includes are most robust to make sure defines are set with future refactorings. * rename Factory fieldFactory Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Add filter for particle histogram (ECP-WarpX#1643) * Add filter for particle histogram * Update benchmarks * Update benchmark again * Use serialize_ics in test + proper usage of RandomEngine * Laser-Ion Acc. (2D3V): Test Hist Filter Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Take time step into account to compute guard cells for J and rho (ECP-WarpX#1607) * Use IntVect for ng_J and ng_rho * Compute guard cells for J and rho based on dt * Reset some CI benchmarks * Fix rebase commit * Add back +1 cell for rho: fix remaining out-of-bound accesses * Simplify ASSERTS using new interface of amrex::numParticlesOutOfRange Modern setup.py: CMake-Driven, Multi-Dimensional (ECP-WarpX#1647) This adds a new, project-centric setup.py file. With this file, all dimensions (2D, 3D, RZ) of WarpX can be built and packaged at once, using the CMake build logic. Build & install: ```bash pip wheel -v . pip install *whl ``` Updates for electrostatic solver (ECP-WarpX#1604) * Fix electrostatic solver with momentum conservation * Fix electrostatic, adding call to FillBoundaryAux * For electrostatic, removed unneeded extra calls to UpdateAux and FillBoundary * For electrostatic, calculate fields at the end of the time step * Updated ElectrostaticSphere analysis script to use fields from end of time step Reset broken benchmark for CI test initial_distribution (ECP-WarpX#1661) make sure we redefine the tmp particle tiles when we load balance. (ECP-WarpX#1658) [mini-PR] Add particle tiling documentation (ECP-WarpX#1665) * tiling wip * do_tiling documentation * Update Docs/source/running_cpp/parameters.rst Co-authored-by: Luca Fedeli <luca.fedeli@for.unipi.it> Co-authored-by: Luca Fedeli <luca.fedeli@for.unipi.it> fix inconsistent formatting (ECP-WarpX#1666) parameter.rst fixes (ECP-WarpX#1663) requirements.txt: fix overspecification (ECP-WarpX#1668) I accidentally added the patch-level for version-compatible matching This removes the patch-level for `~=` matching for the packages that have a >=1 major version already. scipy 1.5+ (ECP-WarpX#1670) Sufficient since it was last release in december and works well. The 3.5 release series still builds wheels for Python 3.6 for Ubuntu oldstable (18.04). Remove redundant "do_qed" option in inputfile (ECP-WarpX#1667) * removed redundant do_qed option in inputfile * fixed bug remove semicolons (ECP-WarpX#1662) fixTypo for pml has particles parameter for docs (ECP-WarpX#1671) load balance efficiency reduced diagnostic eol minor eol

…rpX#1624) * Fix bug in momentum-conserving interpolation function * Reset checksum benchmark for CI test momentum-conserving-gather Unused Params: Check after Step 0 (ECP-WarpX#1596) An early check for unused parameters after the first step. Add Superparticle version of getParticlePosition. (ECP-WarpX#1640) * Add Superparticle version of GetParticlePosition. * move unpack_particle to a free function and rename * no longer need SuperPType * Update Source/Particles/Pusher/GetAndSetPosition.H * remove templating from get_particle_position * remove template * Add missing include Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Distribution mapping and cost plotting (ECP-WarpX#1444) * Distribution mapping and cost plotting Cleanup Cleanup Cleanup EOL Unused import * Cost initializes to 0.0 * plot slices of 3D * WIP * WIP docs * docs * docs * docs * docs * docs * docs * docs * docs * EOL SpeciesProperties: C, N, O, Cu (ECP-WarpX#1638) * SpeciesProperties: C, N, O, Cu Add more ionic species as pre-defined particle species. * Cu: Add to Ionization Energies Fix 2D: ParticleHistogram (ECP-WarpX#1635) Fix out-of-bounds access in particle histogram in non-3D. Fix FilterFunctor in non-3D (ECP-WarpX#1633) Fix an out-of-bounds access to positions in 2D & RZ for filter functors. openPMD: ionizationLevel (ECP-WarpX#1622) * openPMD: ionizationLevel Write out the ionizationLevel with openPMD. * openPMD Record Repetitions: Use Lambdas openPMD: Particle Filter (Container) (ECP-WarpX#1632) * openPMD: Particle Filter (Container) A fresh implementation of particle filters for openPMD diagnostics using the generalized `PhysicalParticleContainer` approach that we also use in plotfiles 🎉 * Ion Example: Filter & Coarsen Test diagnostics filter & coarsen functions in CI. Test reduced diagnostics (histograms). Define: _OPENMP -> AMREX_USE_OMP (ECP-WarpX#1520) * Define: _OPENMP -> AMREX_USE_OMP Replace the define check of `_OPENMP` with the explicit backend control of `AMREX_USE_OMP` for parallel constructs. Doing so avoids that we accidentially turn on OpenMP, e.g. if a dependency pulls it in for linear algebra, I/O, etc. This can led to confusion if the user explicitly requested a serial build. Also, we might want to use OpenMP functionality here and there for auxiliary functions w/o having to use the AMReX OpenMP backend, i.e. because we compile for GPUs. * Add missing amrex::Gpu::notInLaunchRegion Start: PerformanceHints After Init (ECP-WarpX#1630) Start a helper routine that gives performance hints after initialization of the simulation. Fix number of guard cells in PML with 2D PSATD (ECP-WarpX#1648) Remove unused lines about particle filters (ECP-WarpX#1646) Add parameter for default galilean velocity (ECP-WarpX#1097) * Add parameter for default galilean velocity * Apply suggestions from code review Co-authored-by: Edoardo Zoni <59625522+EZoni@users.noreply.github.com> * Fix bug in constructor of PhysicalParticleContainer * Use new input parameter in CI test Co-authored-by: Edoardo Zoni <59625522+EZoni@users.noreply.github.com> Co-authored-by: Edoardo Zoni <ezoni@lbl.gov> Cleaned up field diagnostic in picmi interface (ECP-WarpX#1649) Use pinned memory for tmp particles in diags. (ECP-WarpX#1644) * Use pinned memory for tmp particles in diags. * openPMD: pinned memory (tmp particles) Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Replace an always false test with an abort (ECP-WarpX#1655) * replace always false test with abort * fix bug [mini-PR] Broken link to scripts (ECP-WarpX#1651) CI: Ubuntu-latest -> 20.04 (ECP-WarpX#1654) Start Embedded Boundary development (ECP-WarpX#1641) * Start Embedded Boundary development Modify the build system for embedded boundary (EB) support. Currently EB is a compile time option that must be explicitly enabled. For GNU Make, one can enable it with `USE_EB=TRUE`, whereas for CMake, `-DAMReX_EB=ON`. Later we could decide to enable EB by default with all regular geometry. Add a simple geometry initialization function, WarpX::InitEB. By default, the geometry is all regular. A few basic types such as box, cylinder, plane, sphere, etc. are supported via ParmParse runtime parameters. See `amrex/Src/EB/AMReX_EB2.cpp` for more details. Later, we could build more complex geometry using constructive solid geometry (CSG). ( https://en.wikipedia.org/wiki/Constructive_solid_geometry ) See `amrex/Tutorials/EB/GeometryGeneration` for an example of CSG. There is also a STL ( https://en.wikipedia.org/wiki/STL_(file_format) ) approach under development in AMReX. Add a new member, m_factory, to WarpX class. This object can be used to obtain geometry information such as whether a cell is cut, edge centroids, etc. Currently we are not using these factories to build MultiFabs for field data to embed the geometry information into the data containers. We could do that later if it is needed or it makes things more convenient. Nevertheless, this should be sufficient to start the EB development of the field solver. It's not clear to me yet how many ghost cells are needed for the geometry information. It's currently one, and can be adjusted. In the future, when particle and embedded boundary interaction is considered, we can use `amrex::FillSignedDistance` function to obtain signed distance function on the nodes. With that information, one should be able to determine where and when a particle collides with the embedded boundary. * resize factory vector * CMake: Require AMReX_EB for embedded boundaries * Add AMReX_Config.H et al. Explicit includes are most robust to make sure defines are set with future refactorings. * rename Factory fieldFactory Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Add filter for particle histogram (ECP-WarpX#1643) * Add filter for particle histogram * Update benchmarks * Update benchmark again * Use serialize_ics in test + proper usage of RandomEngine * Laser-Ion Acc. (2D3V): Test Hist Filter Co-authored-by: Axel Huebl <axel.huebl@plasma.ninja> Take time step into account to compute guard cells for J and rho (ECP-WarpX#1607) * Use IntVect for ng_J and ng_rho * Compute guard cells for J and rho based on dt * Reset some CI benchmarks * Fix rebase commit * Add back +1 cell for rho: fix remaining out-of-bound accesses * Simplify ASSERTS using new interface of amrex::numParticlesOutOfRange Modern setup.py: CMake-Driven, Multi-Dimensional (ECP-WarpX#1647) This adds a new, project-centric setup.py file. With this file, all dimensions (2D, 3D, RZ) of WarpX can be built and packaged at once, using the CMake build logic. Build & install: ```bash pip wheel -v . pip install *whl ``` Updates for electrostatic solver (ECP-WarpX#1604) * Fix electrostatic solver with momentum conservation * Fix electrostatic, adding call to FillBoundaryAux * For electrostatic, removed unneeded extra calls to UpdateAux and FillBoundary * For electrostatic, calculate fields at the end of the time step * Updated ElectrostaticSphere analysis script to use fields from end of time step Reset broken benchmark for CI test initial_distribution (ECP-WarpX#1661) make sure we redefine the tmp particle tiles when we load balance. (ECP-WarpX#1658) [mini-PR] Add particle tiling documentation (ECP-WarpX#1665) * tiling wip * do_tiling documentation * Update Docs/source/running_cpp/parameters.rst Co-authored-by: Luca Fedeli <luca.fedeli@for.unipi.it> Co-authored-by: Luca Fedeli <luca.fedeli@for.unipi.it> fix inconsistent formatting (ECP-WarpX#1666) parameter.rst fixes (ECP-WarpX#1663) requirements.txt: fix overspecification (ECP-WarpX#1668) I accidentally added the patch-level for version-compatible matching This removes the patch-level for `~=` matching for the packages that have a >=1 major version already. scipy 1.5+ (ECP-WarpX#1670) Sufficient since it was last release in december and works well. The 3.5 release series still builds wheels for Python 3.6 for Ubuntu oldstable (18.04). Remove redundant "do_qed" option in inputfile (ECP-WarpX#1667) * removed redundant do_qed option in inputfile * fixed bug remove semicolons (ECP-WarpX#1662) fixTypo for pml has particles parameter for docs (ECP-WarpX#1671) Move getCosts Always synchronize nodal points of PML MultiFabs (ECP-WarpX#1669) * Always synchronize nodal points of PML MultiFabs * Reset benchmark for CI test pml_x_psatd * Use new separate functions NodalSyncPML minor

ax3l added install component: Python Python layer labels Jan 22, 2021

ax3l requested a review from dpgrote January 22, 2021 19:19

ax3l assigned dpgrote Jan 22, 2021

ax3l force-pushed the topic-newSetupPy branch 2 times, most recently from e330d1a to d6a4657 Compare January 22, 2021 19:26

ax3l requested a review from RemiLehe January 22, 2021 19:29

ax3l force-pushed the topic-newSetupPy branch 3 times, most recently from b1fb037 to 694aa3b Compare January 22, 2021 20:12

This comment has been minimized.

Sign in to view

ECP-WarpX deleted a comment from lgtm-com bot Jan 22, 2021

dpgrote reviewed Jan 22, 2021

View reviewed changes

ax3l commented Jan 22, 2021

View reviewed changes

setup.py Outdated Show resolved Hide resolved

ax3l force-pushed the topic-newSetupPy branch from 694aa3b to 4ed93b4 Compare January 22, 2021 23:18

ECP-WarpX deleted a comment from lgtm-com bot Jan 22, 2021

ax3l force-pushed the topic-newSetupPy branch from 4ed93b4 to baab99d Compare January 23, 2021 00:42

ECP-WarpX deleted a comment from lgtm-com bot Jan 23, 2021

ax3l force-pushed the topic-newSetupPy branch 3 times, most recently from e8ba28e to e50f895 Compare January 25, 2021 20:12

ax3l commented Jan 25, 2021

View reviewed changes

Docs/source/building/cmake.rst Show resolved Hide resolved

ax3l force-pushed the topic-newSetupPy branch 2 times, most recently from a21226e to 50b72d1 Compare January 25, 2021 21:23

Modern setup.py: CMake-Driven, Multi-Dimensional

0c02e20

This adds a new, project-centric setup.py file. With this file, all dimensions (2D, 3D, RZ) of WarpX can be built and packaged at once, using the CMake build logic. Build & install: ```bash pip wheel -v . pip install *whl ```

ax3l force-pushed the topic-newSetupPy branch from 50b72d1 to 0c02e20 Compare January 25, 2021 21:25

dpgrote reviewed Jan 27, 2021

View reviewed changes

dpgrote approved these changes Jan 27, 2021

View reviewed changes

ax3l merged commit 1014a48 into ECP-WarpX:development Jan 27, 2021

ax3l deleted the topic-newSetupPy branch January 27, 2021 19:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Modern setup.py: CMake-Driven, Multi-Dimensional #1647

Modern setup.py: CMake-Driven, Multi-Dimensional #1647

ax3l commented Jan 22, 2021 •

edited

Loading

This comment has been minimized.

This comment has been minimized.

dpgrote Jan 22, 2021

ax3l Jan 22, 2021

ax3l Jan 25, 2021

ax3l Jan 26, 2021

dpgrote Jan 27, 2021

ax3l Jan 27, 2021 •

edited

Loading

dpgrote Jan 27, 2021

ax3l Jan 27, 2021 •

edited

Loading

dpgrote Jan 27, 2021

ax3l Jan 27, 2021 •

edited

Loading

dpgrote Jan 27, 2021

dpgrote Jan 27, 2021

ax3l Jan 27, 2021 •

edited

Loading

dpgrote Jan 27, 2021

ax3l Jan 27, 2021 •

edited

Loading

dpgrote left a comment

Modern setup.py: CMake-Driven, Multi-Dimensional #1647

Modern setup.py: CMake-Driven, Multi-Dimensional #1647

Conversation

ax3l commented Jan 22, 2021 • edited Loading

To Do

Future

This comment has been minimized.

This comment has been minimized.

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 Jan 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ax3l Jan 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ax3l Jan 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ax3l Jan 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ax3l Jan 27, 2021 • edited Loading

Choose a reason for hiding this comment

dpgrote left a comment

Choose a reason for hiding this comment

ax3l commented Jan 22, 2021 •

edited

Loading

ax3l Jan 27, 2021 •

edited

Loading

ax3l Jan 27, 2021 •

edited

Loading

ax3l Jan 27, 2021 •

edited

Loading

ax3l Jan 27, 2021 •

edited

Loading

ax3l Jan 27, 2021 •

edited

Loading