A question of gradient calculation when backward with CPML about deepwave

[ar4]

Using TorchScript might also make your code run faster, too, so I think it is worth the effort of making sure you write your code in a way that torch.jit.script can be applied to it.

Do you create ax and bx using the setup_pml code from Deepwave? Printing the value of ax.requires_grad and bx.requires_grad inside your rs_cpml_absorb function would be useful to verify that it didn't get set to True somehow for them.

[ar4]

If you did use Deepwave's setup_pml, is it possible that you passed the max_vel value using v.max() rather than v.detach().max(), and so the max_vel value has requires_grad=True, causing ax and bx to also have it set to True?

[YingchangLiu]

Thank you very much， Dr Richardson.

The problem is indeed ax.require_grad. As you mentioned, I use the velocity parameter directly when calculating max_vel.

v_max=torch.max(vp)
az,bz,ddz,ax,bx,ddx = rs_cpml_parameter(vshape=self.mesh.shape,dzyx=self.mesh.size,H=self.mesh.H,vp_max=v_max,fm=self.source.f0,dt=self.mesh.dt,device=self.device)

That's amazing! Your programming ability and expertise amaze me.

Thanks for your solution!

[YingchangLiu]

In addition, cpml greatly increases the memory requirements of the computation graphs. I'm thinking of replacing it with a simple sponge boundary condition.

[ar4]

Hello @kelen51215

Does this mean that installation of Deepwave on Windows is still a problem, and that is why you have resorted to writing a pure PyTorch version?

I don't see any problem in the code that you provided, so I suspect that the problem must be occurring elsewhere. Are there any inplace operations (like a += b) in your code? Have you tried running with torch.autograd.set_detect_anomaly(True) to see if it provides more clarity on where the problem is occurring?

There are definitely advantages of just using a simple sponge boundary in certain situations. The absorption will probably not be as good as with CPML, but I suspect that it will indeed reduce the memory usage when relying on automatic differentiation.

[YingchangLiu]

The new version of deepwave works well on Windows.

I am testing anisotropic parameter inversion, so I rewrote the package for flexibility.

The inplace operations have been removed earlier. This problem only occurs when adding CPML boundaries. I am using detect_anomaly to detect where the problem occurred.

[ar4]

That is good news about Windows.

I just noticed in the code you showed there is the line

wavefield.p +=  self.mesh.dt * Mp * (dvxdx + dvzdz)

An in-place operation like that might cause problems. I suggest changing it to

wavefield.p = wavefield.p + self.mesh.dt * Mp * (dvxdx + dvzdz)

and the same with any other inplace operations that you have.

[YingchangLiu]

Copy that!

I'm sure all += and *= are removed from the program, and I'm replacing the element.

Just discovering that either ax or bx exists causes an error. Replacing them with a constant will not result in an error. I'm trying to find out why. Thank you for your advice.

def rs_cpml_absorb(dpdx, cpml_dpdx ,ax, bx, kkx):
    cpml_dpdx = bx * cpml_dpdx + ax * dpdx
    dpdx = dpdx / kkx + cpml_dpdx
    return dpdx, cpml_dpdx

[ar4]

That is quite strange. I cannot see any problem with that code. One idea that might help to diagnose the problem is to run your code through PyTorch's TorchScript interpreter. You will need to specify the types of inputs and outputs of all of your functions that are not Tensors, and then call torch.jit.script(). The error messages from the interpreter are sometimes more detailed and so might indicate where the problem is.