empty tar #392
-
hi.when i run the following code i get an empty myeko.tar and the program stops responding: import pathlib
import eko
from ekobox.cards import example
if __name__ == '__main__':
th_card = example.theory()
op_card = example.operator()
op_card.xgrid = [1e-3, 1e-2, 1e-1, 5e-1, 1.]
path = pathlib.Path("./myeko.tar")
path.unlink(missing_ok=True)
eko.solve(th_card, op_card, path) and if i try to read the tar file using this code: import eko
with eko.EKO.read("./myeko.tar") as evolution_operator:
# obtain theory card
print(evolution_operator.theory_card)
# or operator card
print(evolution_operator.operator_card)
print(evolution_operator.evolgrid) i get the following result:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
Hey @uncertainty-principle , Unfortunately I can not reproduce your behavior - instead for me it works as expected and I get the expected tuple However, I'm guessing the problem is here: "the program stops responding" - unfortunately this is currently a "bad feature" of eko. The problem is eko is relying on numba for a fast evaluation of the underlying integrals. This implies a compilation from Python to machine code (which is then quick to execute) and this compilation is done just-in-time (JIT), which in practice is on the first actual call. Since we have a quite big code base (with many mathematical non-trivial functions) this actually requires some time and it may indeed seem that the program stops responding. Depending on the complexity you ask (and your machine) this can take up to 30 min. However, once the compilation is done it is cached and then reused every time you ask eko again. Can you please try again and let it run a bit longer? I would also recommend to adjust the operator card for the first run (and as explained only the first) and set We are working on a solution to the problem by using Rust for the hard math and thus compiling at wheel creation time. PS: Note that the |
Beta Was this translation helpful? Give feedback.
Hey @uncertainty-principle ,
thanks for reaching out.
Unfortunately I can not reproduce your behavior - instead for me it works as expected and I get the expected tuple
[(10000.0, 5)]
back for the last print.However, I'm guessing the problem is here: "the program stops responding" - unfortunately this is currently a "bad feature" of eko. The problem is eko is relying on numba for a fast evaluation of the underlying integrals. This implies a compilation from Python to machine code (which is then quick to execute) and this compilation is done just-in-time (JIT), which in practice is on the first actual call. Since we have a quite big code base (with many mathematical non-trivial functions)…