Giter Club home page Giter Club logo

emu's People

Contributors

dwillcox avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

emu's Issues

grid initialization

Currently the code crashes with an arithmetic error if everything is not set to zero first (msw_test branch). Should figure out what needs to be initialized and explicitly initialize it in main.cpp.

Move Redistribute to end of timestep instead of post update

Andrew has suggested an optimization where instead of redistributing in the post_update step, we add an additional ghost zone and redistribute at the end of every timestep.

This requires that particles in that extra ghost zone deposit & interpolate.

WarpX's shape factors by default won't allow this, as they use integer casting to get the leftmost cell where a particle deposits. Because C++ integer casting rounds towards 0, this will say that for particles in grid cell -1, the leftmost cell is 0 instead of -1.

We can fix this by modifying the shape factor structs like this:

const T x = xmid + T(0.5);
const auto i = static_cast<int>(x);
const auto j = std::signbit(x) ? i-1 : i;

And while we're at it, remove the Esirkepov shape factors we're not using.

particle "length" interpretation is wrong

Right now the implementation of the "length" of the particle needs to be generalized to three flavors. Right now it only works for two. In the case where there are initially no heavy lepton neutrinos it doesn't matter (the evolution equations are the same), but should be fixed for the future.

Sort particles

For the Cori GPU test profiling, particle to mesh is 65%, and mesh to particle is 17%.

If we did a sort of tree reduction for the atomics, by reducing in warps first, then to global memory, maybe we could greatly reduce this disparity.

Save particles

Save particles to plotfiles (optional)

Save particles to checkpoint files

Report error in the trace of particle density matrices

We can report the L2 and max norm of the error in the trace of the particles' density matrices.

Currently, for each particle the flavor vector length L is calculated from N_ab, the matrix storing the number of neutrinos in each state. We also have the particle weight N_p which is just the number of neutrinos in each particle.

Error in Tr(rho) = 1 can significantly affect the number of neutrinos that transform if L ~ N_p, since the size of L controls the maximum amount of flavor transformation. We can define an error E = |L(rho) * N_p - L_0| where L_0 is the initial length stored in the particles and L(rho) * N_p is the flavor vector length calculated from rho, scaled by the particle weight. Then take the L2 and max norms of E by computing Ep^2 for each particle and depositing it onto the grid E, then use sum and max to get L2 and max norms on the grid.

We can then add an input parameter for the error reporting frequency, like report_error_every.

The idea is that this will tell us when our simulations would benefit from symbolically making the assumption that Tr(rho_ab) = 1 => Tr(N_ab) = N_p, eliminating one of the diagonal components algebraically, and evolving a traceless matrix N_ab_p for particles.

Implement error-based adaptive timestepping

Adapt the timestep to the current error estimate, perhaps taking a min of the adaptive timestep and the timestep determined from the neutrino potential as in #57

We could use, e.g. RK45 or Richardson extrapolation.

Store density & flux density on grid

We currently store number of neutrinos in a grid cell Nab, same for flux, because we divide by cell volume in the interpolation step.

We can move the cell volume division into the deposition step, so our grid quantities are more typical number density & flux density.

add gitpod back into readme

Removed gitpod to minimize maintenance area since I am the only one maintaining for now. Would be great to update it and put it back.

optimize redistribute

To get the code running on GPUs we made the redistribute global. With local redistribute, it was asserting that the number of particles out of bounds must be zero. We should return to local redistribute for efficiency.

Timestep reporting on output

The timestep is reported wrongly when recovering from output. If a checkpoint is written at timestep 1000, when restarting from that checkpoint the output says "restarting from checkpoint 999".

gpu-compilable code

The changes to FlavoredNeutrinoContainer.cpp_Renormalize_fill do not allow for compiling on gpus because of the use of std::string

Descriptive Aborts

Sometimes we use Abort() which just generates a backtrace.

It would be much easier to understand why the code stopped if we replace all uses of amrex::Abort() with amrex::Error("An error message.") -- it will behave the same way as Abort() but print a helpful message :)

optimize timestep

the timestep uses the largest diagonal component. Rather, we should calculate the length of the Hamiltonian isospin vector for each grid cell. This could lead to significant speedup at late times when decoherence shrinks the grid isospin vector length.

README / license

Before releasing we should write a readme that describes what the code does, basic configuration and running, and have an open-source license. The header of each file should also contain a brief copyright.

Compute runtime diagnostics

Compute runtime diagnostics every so many steps.

To start, can simply implement the sums & averages from reduce_data.py using AMReX reductions.

We'll have to generate code for the reduction kernels & reduction variables, ofc.

Save the reduced data into an HDF5 file with an entry per diagnostic timestep.

Also, when we restart from a checkpoint, if that HDF5 file is in the current directory, we should delete entries at timesteps later than the restart timestep before resuming the simulation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.