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.

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

Addition: Mask kernels at the source element #1178

Open
evcano opened this issue Mar 13, 2023 · 2 comments
Open

Addition: Mask kernels at the source element #1178

evcano opened this issue Mar 13, 2023 · 2 comments

Comments

@evcano
Copy link
Contributor

evcano commented Mar 13, 2023

Hi @danielpeter,

The sum_kernels subroutine has the option to mask the kernels at the source element using a mask. However, the mask is not computed in any part of the code. I added a subroutine to compute and save the mask in a binary file. Can you please check my branch #c9bbc78 and tell me if looks good?

Also, I would like to add a flag in order to avoid writing the mask always. Should I reuse USE_SOURCE_MASK defined in setup/constants_tomography.h?

Alternatively, one could save the muted kernels directly instead of saving the mask, what do you think is a better option?

Best wishes.

PS: Does ispec_selected_source returns the global element number or on the slice?

@danielpeter
Copy link
Contributor

danielpeter commented Mar 13, 2023

hi Eduardo,

you’re right, in the 2D and 3D_Cartesian version this mask is not created yet, only in the GLOBE version. so, the USE_SOURCE_MASK is more like a placeholder for future use. in the GLOBE version, we do create the mask. you could follow the SAVE_SOURCE_MASK flag in the code, a parameter we also added to the Par_file.

note that the mask created in your branch wouldn't work. the mask has a value from 1 away from the sources, and goes smoothly to zero at the source positions. only this way, the product of kernel * mask damps out the source positions.

be aware that this is an experimental feature. the mask needs some damping value for a Gaussian function, to determine how fast the mask values should drop to zero around the source positions. this is hard-coded at the moment and determined relative to the element size. so, i’m not sure if anybody is using that feature, since to actually use the mask, we turned the USE_SOURCE_MASK flag to .false. for the sum_kernels tools in the constants_tomography.h file. this means, one would need to recompile the whole source code to use the feature, even when the mask was created by the user Par_file flag. this could be simplified and modified a bit as well. for example, the code could check if the mask files are available in the INPUT_KERNELS/ folder and if so, then they would be used automatically to avoid this constant USE_SOURCE_MASK flag. something similar we do already for example for GLL model files in different regions.

regarding having this mask separated, i think that is okay since it is a strong assumption. adding a source mask is an additional regularization term in the optimization problem. the main question then is, does it make sense to add such a regularization? why do we assume the velocity perturbations must be away from the source positions? this only makes sense if we would know the structure around the source better than elsewhere, and so assume that our initial model has good values around those locations, but bad values further away. i don’t see how this is justified at least at regional/global scale models. maybe for exploration, when you have some drilling done beforehand to have an extra handle on those locations.

furthermore, if we damp the sources, shouldn’t the receiver locations be damped as well? the kernels have singularities a both, source and receiver locations, so damping the receivers would follow the same argumentation as the sources. however, a receiver mask is not implemented yet. so, that would need to be added as well.

a different approach followed so far was to smooth the kernels with a Gaussian width at least as short as the minimum wavelength supported by the simulations. this will balance out the strong sensitivities at source and receiver positions. and this could be combined with better measurements, like double-difference measurements which take out some of the sensitivity around source/receiver locations.

anyway, if you want to implement the source mask and experiment a bit with it, go for it :)

@evcano
Copy link
Contributor Author

evcano commented Mar 14, 2023

Hi @danielpeter,

Thanks for the detailed answer. I agree that masking the sources/receivers is a heuristic regularization without a strong theoretical justification. However, I noticed that the sensitivities around the sources/receivers still remain high after smoothing. That is why I want to experiment with the mask. Maybe the mask can be used to down-weight the kernel without making it exactly zero at the sources/receivers. I am planning to first apply the mask and then smooth the kernels. Thus, the model will still be updated everywhere.

Thanks for pointing out how the mask should work. I will try to implement it for both sources and receivers by following SPECFEM_GLOBE and let you know here once I finish. Even if I do not end up using it, maybe someone else will.

Best regards.

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

No branches or pull requests

2 participants