When calculating with Firedrake, the calculation is aborted. How do I resolve it? about firedrake

[connorjward]

OSError: /home/zhan/Desktop/Zhan/6d/0de3c0e4ecf8614b3892628044d2f2.so: cannot apply additional memory protection after relocation: Cannot allocate memory

Your computer appears to be running out of memory. If you use a system resources viewer like htop you would be able to verify this.

To resolve this you could either try running on a machine with more memory or reduce the problem size. It's also possible that you have introduced some sort of memory leak breaking Python's ability to garbage collect old objects. Can you provide some more information about the simulation you are running?

[wence-]

That error usually occurs if you have a timestepping (or similar) loop, and are doing some assignment or computation that has a dependence on a literal numeric value.

For example, a typical thing you might think to write is:

t = 0
while t < t_end:
    t += dt
    some_form_with_t_in_it = ... t ...
    assemble(some_form_with_t_in_it) # or solve, or interpolate, ...

This will provoke compilation of a new kernel on every iteration and eventually produce this error.

The correct usage is to wrap literal constant values that are updated in a loop like this in a Constant, and use assign:

t = Constant(...)
some_form_with_t_in_it = ... t ...
while float(t) < t_end:
    t.assign(t + dt)
    assemble(some_form_with_t_in_it)

[qk11853]

That error usually occurs if you have a timestepping (or similar) loop, and are doing some assignment or computation that has a dependence on a literal numeric value.

For example, a typical thing you might think to write is:

t = 0
while t < t_end:
    t += dt
    some_form_with_t_in_it = ... t ...
    assemble(some_form_with_t_in_it) # or solve, or interpolate, ...

This will provoke compilation of a new kernel on every iteration and eventually produce this error.

The correct usage is to wrap literal constant values that are updated in a loop like this in a Constant, and use assign:

t = Constant(...)
some_form_with_t_in_it = ... t ...
while float(t) < t_end:
    t.assign(t + dt)
    assemble(some_form_with_t_in_it)

Could you please give me more details of the code? I don't quite understand it.
Thank you very much.

[connorjward]

That error usually occurs if you have a timestepping (or similar) loop, and are doing some assignment or computation that has a dependence on a literal numeric value.
For example, a typical thing you might think to write is:

t = 0
while t < t_end:
    t += dt
    some_form_with_t_in_it = ... t ...
    assemble(some_form_with_t_in_it) # or solve, or interpolate, ...

This will provoke compilation of a new kernel on every iteration and eventually produce this error.
The correct usage is to wrap literal constant values that are updated in a loop like this in a Constant, and use assign:

t = Constant(...)
some_form_with_t_in_it = ... t ...
while float(t) < t_end:
    t.assign(t + dt)
    assemble(some_form_with_t_in_it)

Could you please give me more details of the code? I don't quite understand it. Thank you very much.

The core difference here is what is getting passed to assemble(...) (though the same logic would apply to solve(...) and other Firedrake functions).

If you are assembling something with a literal number like 1.68 * u * v * dx then this number will get embedded in the generated code, so if you change the number to, say, 1.72 * u * v * dx then brand new code will be generated. If you do this a lot such as in a timestepping loop, then you can end up having the sorts of issues that you describe.

The trick to fixing this is to wrap the literal value in a Firedrake Constant type. E.g. Constant(1.68) * u * v * dx. Then if you later assemble Constant(1.72) * u * v * dx then no new code is generated.

This is described here in the manual.

[qk11853]

That error usually occurs if you have a timestepping (or similar) loop, and are doing some assignment or computation that has a dependence on a literal numeric value.
For example, a typical thing you might think to write is:

t = 0
while t < t_end:
    t += dt
    some_form_with_t_in_it = ... t ...
    assemble(some_form_with_t_in_it) # or solve, or interpolate, ...

This will provoke compilation of a new kernel on every iteration and eventually produce this error.
The correct usage is to wrap literal constant values that are updated in a loop like this in a Constant, and use assign:

t = Constant(...)
some_form_with_t_in_it = ... t ...
while float(t) < t_end:
    t.assign(t + dt)
    assemble(some_form_with_t_in_it)

Could you please give me more details of the code? I don't quite understand it. Thank you very much.

The core difference here is what is getting passed to assemble(...) (though the same logic would apply to solve(...) and other Firedrake functions).

If you are assembling something with a literal number like 1.68 * u * v * dx then this number will get embedded in the generated code, so if you change the number to, say, 1.72 * u * v * dx then brand new code will be generated. If you do this a lot such as in a timestepping loop, then you can end up having the sorts of issues that you describe.

The trick to fixing this is to wrap the literal value in a Firedrake Constant type. E.g. Constant(1.68) * u * v * dx. Then if you later assemble Constant(1.72) * u * v * dx then no new code is generated.

This is described here in the manual.

Thank you very much for your patient answer!