Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Integrators - minimal working example for higher order integration methods #1449

Open
dom-kufel opened this issue Mar 19, 2023 · 1 comment
Open

Integrators - minimal working example for higher order integration methods #1449

dom-kufel opened this issue Mar 19, 2023 · 1 comment

Comments

@dom-kufel
Copy link

Hi, I am interested in a minimal working example for using higher order integration methods. I cannot immediately see how does their implementation work. For instance, given a TDVP linear ODE in custom_simple_tdvp() from https://scipost.org/SciPostPhysCodeb.7/pdf how would you modify simple Euler rule to e.g., RK12 while utilizing methods from netket.experimental.dynamics?
@dom-kufel dom-kufel changed the title Integrators - minimal working example for custom TDVP Integrators - minimal working example for higher order integration methods Mar 22, 2023
@jwnys jwnys mentioned this issue Apr 5, 2023
Closed
@lindamauron lindamauron mentioned this issue Sep 26, 2024
Merged
PhilipVinc added a commit that referenced this issue Oct 2, 2024
@lindamauron @PhilipVinc
Make ODE solvers more readable and flexible (#1933)
63e3c31 
As previously mentioned (see #1456 or #1449), the structure of
`RKIntegrator` is quite intricate and complicated to address. This PR
basically creates super-classes which contain all the complicated stuff
(like the `IntegratorState` or the `adaptive_step`), from which the
Runge-Kutta integrators inherit. The benefit is that now, to define the
RK-integrator (or any other new integrator), one only needs to define a
new `Tableau` which contains the requested methods, namely the `step`
method and simple information about the integrator (like order,
adaptivity etc.).

Changes include 
- creation of these super-classes and definition of the RK solvers as
inheritance (subfolder)
- addition of comments and definitions of functions here and there,
where it felt they were missing
- modification of any code which uses integrators (usually replacing
`RKIntegrator...` -> `Integrator...`)
- modification of the tests accordingly. As a detail, the tests checking
the accuracy of the solvers now compare to an analytical solution
instead of a numerical one (same ODE, just not using `scipy` anymore)

In practice, the usage remains the same, only the internal structure
changes. The reason for this code is that I had a custom integrator for
which I created this whole structure, so I am sharing it here

---------

Co-authored-by: Filippo Vicentini <[email protected]>
@PhilipVinc
Copy link
Member

Must still document this, but the interface is now decently defined...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@PhilipVinc @dom-kufel