Skip to content

Conversation

@jpbrodrick89
Copy link
Contributor

@jpbrodrick89 jpbrodrick89 commented Jan 31, 2026

I still need to go over the tests, they are purely done by Claude but seem pretty robust, though I haven't even read them! 🙈

Nevertheless, I'm pretty happy with the overall design which leaves open the door to many opportunities for other models, algorithms and heating/cooling physics.

Key numerical changes these affect vfp1d, _vlasov1d and vlasov1d2v (vlasov2d unaffected for now):

  • True zero flux boundary conditions implemented which maximises both Maxwellian preservation and conversation of density. Previously, I think it was effectively Dirichlet which acts as a particle sink. Afaiu zero flux is most commonly used and recommended by Chang-Cooper.
  • Central differencing is a little janky due to the drift term being defined on cell edges but I think it has a chance of still being second order accurate (haven't put any thought into this whatsoever), we could just interpolate from edges back to centres but central differencing has loads of bad properties I don't really see why we'd keep it (we can address energy density in other ways going forward).
  • Lineax used for all tridiagonal solves (performance issues should be adressed by v0.1.0)

Limitations:

  • Currently isn't set up to support spatially varying dv but easy extension (spatially varying nu, C, D are all supported)

Choices:

  • Models could maybe be moved to their adept modules as there is no reuse of these
  • If you want me to move any files or put in a subdirectory or rename of course more than happy to do that

Copy link
Member

@joglekara joglekara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

:param nu: collision frequency
:param f_xv: the distribution function at all locations in space (nx, nv)
:param dt: the time step
return lx.linear_solve(op, f0, solver=lx.AutoLinearSolver(well_posed=True)).value
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason to do this over tridiagonal explicitly?

Copy link
Contributor Author

@jpbrodrick89 jpbrodrick89 Jan 31, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly if we decide to use other operators in the future (e.g. dense Epperlein 94 or another sparse form). I'd you'd rather take the YAGNI approach until we actually do happy to revert.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants