[rsf-devel] sfawefd2d in 1.7 vs 1.6.5

[Dale Harger]

I reported an issue a week or so ago. I did not have time to document the details, but I do now.

 

I was having stability issues running sfawe2d in 1.7. As I back tracked the problem I eventually backed all the way up to run the simple example at http://ahay.org/wiki/Guide_to_madagascar_programs#sfawefd2d

 

This did not successfully run, so I tried it in 1.6.5 That worked fine.

 

I can’t recall whether I have seen attachments in the mailing list, so I will upload diagnostic files to google-drive for viewing. I tried to set them all to accept comments and/or to be downloaded.

 

The wavefield and receiver data plots for 1.6.5 are located here;

 

Wfld165.jpeg -> https://drive.google.com/file/d/0B7rh9upNIWrMWHItMVZKSGptRXM/view?usp=sharing

Data165.jpeg -> https://drive.google.com/file/d/0B7rh9upNIWrMdGk3QzRFVExVY1E/view?usp=sharing

 

They match expectations.

 

The setup file is exactly as indicated in the above example except I changed;

(1)    Added cden=n. This is the default, so should not make a difference. Added because in 1.7 cden=n appears to be required or the program ignores the den= file. I wanted the setups to be identical so added cden to the 165 setup.

(2)    Changed free=y to fsrf=y. free=y does invoke a free surface in 165.

(3)    Changed the pen commands to save vpl and jpegs.

 

In case anybody wants them, here is the mad command file and the wave filed movie vpl file;

 

Command file -> https://drive.google.com/file/d/0B7rh9upNIWrMeTZaeDdXN1prVVE/view?usp=sharing

Movie vpl -> https://drive.google.com/file/d/0B7rh9upNIWrMUmk5VjJKNE44Ylk/view?usp=sharing

 

Note that last link is the raw vpl file. There will be no google-drive preview. Download the file and process through sfpen.

 

Now when I switch to 1.7 the story changes;

 

First let me say that though I wanted the setups to be identical, the result go unstable very quickly if cden=n and mask what may be going on. So these results are with cden=y. With cden=n the results are worse. Even though recall that in this case the density file provided is constant density.

 

And as a side note – If den=denfile.rsf is coded, but no cden=y is also included then there is a message “sfawefd2d: No density file provided,  running with constant density”

 

Second I changed gainpanel=e in the movie creation as the amplitudes increase quickly and a single scalar masks the early results.

 

Wfld17.jpeg -> https://drive.google.com/file/d/0B7rh9upNIWrMaU1mUTIxSmtJdHc/view?usp=sharing

Data17.jpeg -> https://drive.google.com/file/d/0B7rh9upNIWrMR2JvdmFaZFUwZWc/view?usp=sharing

Command file -> https://drive.google.com/file/d/0B7rh9upNIWrMbGRERUY4R3F3eVE/view?usp=sharing

Movie vpl -> https://drive.google.com/file/d/0B7rh9upNIWrMUDhHZHZFUS1falU/view?usp=sharing

 

This is an early snapshot of the wavefield and you can see there seems to be some leakage between code arrays.

 

Wfldearly.jpeg -> https://drive.google.com/file/d/0B7rh9upNIWrMSWF4dzZUZmVxR3c/view?usp=sharing

 

I suspect that array leakage is the bug. Though it is possible that since the moment in time that I compiled 1.6.5 there has been a compiler or other system/dependency update that has changed something that is the root cause instead of a code issue.

 

Dale Harger