In some cases, models can only be used in one fit page at a time

[butlerpd]

I suspect this is related to #1454 and #1546. But I would argue in some senses worse, though both really preclude the use of SasView for a real project I think.

In this case, if you send to different datasets to two different fitpages all is well. Then choose a model o fitpage one to fit that data. If you now try to use the same model to fit the data on the second page, a permission denied error is thrown. Due to some other logic errors in the GUI to be documented next, it seems that the problem is that the model is tied to first fitpage and will not allow the second fitpage to overwrite its parameters.

NOTE: This is an extremely common situation for an experiment where I may have lots of concentrations, different shear rates, temperatures etc etc but the fundamental shape will not change ..until maybe some critical point)

[rozyczko]

That's some really bizarre behaviour - I can't reproduce it locally and it sounds very troubling if indeed not a fluke?

[rozyczko]

What I did:

1. loaded two datasets into DE
2. sent them to two separate fit pages
3. chose model1 (barbell) in fit page 1
4. chose model2 (cylinder) in fit page 2
5. made a simple fit of scale in 1
6. made a simple fit of scale in 2
7. in fit page 2 changed model to model1 (barbell)
8. reran fitting

[butlerpd]

Interesting. The difference is that I never tried a different model first so

1. load two data sets
2. select one data set and send to fit page
   • data is sent to the first fitpage
3. select a model and show plot (works as expected)
4. select second data set and sent to fit page
   • a fitpage 2 is created
5. select the SAME mode as just used on fitpage 1 (which is still selected of course because that was the fit (so in your case would be barbell never touch cylinder.. why would I do that I am working with a nanoparticle system with different concentrations and different preparation methods so of course all will be same basic shape 😃
6. error is thrown as soon as the model tries to compute

I did play around a tiny bit with trying to change the model on fitpage one and it seemed to unlock fitpage 2 .. once but then both were locked up and other strange things. Was getting too complicated to be sure to document something reproducible. But if you can start the second fitpage with a different model then come back it must be something in the initialization?

I will admit here to using the PR build (from jenkins) of Miguel as I am trying to test the functionality of his smearing fixes ... and been constantly distracted by these bugs 🤕 at least it sounds like a good excuse for why I'm not making rapid progress 😄

[pkienzle]

On mac ESS_GUI using latex_smeared.xml I can fit both curves to a sphere model, separately or simultaneously.

[rozyczko]

I tried your sequence, @butlerpd and still can't reproduce the failure. Let's ask others!

[butlerpd]

Maybe there was another change that fixed this since Miguel branched? It is quite reproducible for me (though I always start from fresh ... otherwise I have not idea what state things are in). I have however just verified that if I send the two latex files simultaneously to fitting then I have no conflict. Will try a few more permutations to see what I find

[pkienzle]

No problem with this sequence on Mac on ESS_GUI and on ESS_GUI_1547_smearing. I used AOT drop and core contrast, both plotted with barbell.

[butlerpd]

Right .. now I am very confused ... and worried. I have not only verified that sending 2 curves to fitting simultaneously (not necessarily latex file with 2 data sets in the same file) works, but I can no longer reproduce the error. Literally after every effort I would quit SasView and then launch it again so always starting from same state. It is a PR build download from Jenkins so not dependent on my system in principle. And I have done nothing else on this system all day except launch and quit SasView. I was able to consistently reproduce the error a dozen times or so (from memory but also looking at the log file). Speaking of lof file .. DUH! I should have attached it from the start. It was failing on a model compile. Attach the whole output here:

2020-05-28 15:15:06,693 : INFO : root (kerneldll.py:194) :: "C:\Program Files\SasView\tinycc-data\tcc.exe" -shared -rdynamic -Wall C:\Users\PAPERS~1\AppData\Local\Temp\1\sas64_sphere__at4gp1d.c -o C:\Users\paperspace\.sasmodels\compiled_models\sas64_sphere.so
2020-05-28 15:15:06,829 : ERROR : sas.qtgui.Perspectives.Fitting.FittingWidget (FittingWidget.py:3027) :: Traceback (most recent call last):
  File "C:\Program Files\SasView\sasmodels\kerneldll.py", line 198, in compile_model
    subprocess.check_output(command, shell=shell, stderr=subprocess.STDOUT)
  File "subprocess.py", line 356, in check_output
  File "subprocess.py", line 438, in run
subprocess.CalledProcessError: Command '['C:\\Program Files\\SasView\\tinycc-data\\tcc.exe', '-shared', '-rdynamic', '-Wall', 'C:\\Users\\PAPERS~1\\AppData\\Local\\Temp\\1\\sas64_sphere__at4gp1d.c', '-o', 'C:\\Users\\paperspace\\.sasmodels\\compiled_models\\sas64_sphere.so']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "site-packages\sasview-5.0.2-py3.6.egg\sas\sascalc\data_util\calcthread.py", line 269, in _run
  File "site-packages\sasview-5.0.2-py3.6.egg\sas\qtgui\Perspectives\Fitting\ModelThread.py", line 179, in compute
  File "C:\Program Files\SasView\sasmodels\sasview_model.py", line 715, in calculate_Iq
    return self._calculate_Iq(qx, qy)
  File "C:\Program Files\SasView\sasmodels\sasview_model.py", line 723, in _calculate_Iq
    self.__class__._model = core.build_model(self._model_info)
  File "C:\Program Files\SasView\sasmodels\core.py", line 339, in build_model
    return kerneldll.load_dll(source['dll'], model_info, numpy_dtype)
  File "C:\Program Files\SasView\sasmodels\kerneldll.py", line 304, in load_dll
    filename = make_dll(source, model_info, dtype=dtype)
  File "C:\Program Files\SasView\sasmodels\kerneldll.py", line 286, in make_dll
    compile_model(source=filename, output=dll)
  File "C:\Program Files\SasView\sasmodels\kerneldll.py", line 201, in compile_model
    raise RuntimeError("compile failed.\n%s\n%s"%(command_str, output))
RuntimeError: compile failed.
"C:\Program Files\SasView\tinycc-data\tcc.exe" -shared -rdynamic -Wall C:\Users\PAPERS~1\AppData\Local\Temp\1\sas64_sphere__at4gp1d.c -o C:\Users\paperspace\.sasmodels\compiled_models\sas64_sphere.so
C:/Program Files/SasView/sasmodels/models/sphere.c: warning: unknown escape sequence: '\P'

C:/Program Files/SasView/sasmodels/models/sphere.c: warning: unknown escape sequence: '\S'

C:/Program Files/SasView/sasmodels/models/sphere.c: warning: unknown escape sequence: '\s'

C:/Program Files/SasView/sasmodels/models/sphere.c: warning: unknown escape sequence: '\m'

C:/Program Files/SasView/sasmodels/models/sphere.c: warning: unknown escape sequence: '\s'

tcc: error: could not write 'C:\Users\paperspace\.sasmodels\compiled_models\sas64_sphere.so': Permission denied

[pkienzle]

There should not be any quoted strings in the C code, and not with backslashes. The code it is trying to compile may still be in:

C:\Users\PAPERS~1\AppData\Local\Temp\1\sas64_sphere__at4gp1d.c

You can peek in there to see what might be going wrong.

The "could not write file" problem could happen if you have two versions of the program open at once. You can see that I'm using the same name for the module regardless of which version of sasview is running, so there will be collisions. Once one windows program has the dll open, no other program write to it. See also #1534.

It still doesn't explain what is going wrong starting the same model on two different pages. I don't think that can trigger a recompile.

[butlerpd]

That is interesting... so I did "peak" and there were a series of sas64_sphere_####.c where #### looks like some hash. All were created today. Looking at the one you pointed to it does in fact have lots of quotes. These are either in comment lines // xxxx and all but one case the others are in line like the following where the final parameter might vary

#line 1 "C:/Program Files/SasView/sasmodels/kernel_iq.c Imagnetic"

Regarding your other point. No, I'm afraid I try to keep the system fairly clean. It has not had 4.x on it for a while. The last month or so it has been 5.0.2 release. This morning I removed that installation and then installed the PR installation from jenkins.

I only had one instance of SasView open at one time (I did not have two instances running at once).

[butlerpd]

And for a nice irony twist. I uninstalled the resolution PR build and replaced with the MPL toolbar PR to test those changes ... and encountered the exact same failure straight out of the chute 😄 (same send to fit then send a second one to fit and use the same model. Hoping that @pkienzle sasmodels fix will fix this issue?

[butlerpd]

And again testing PR build 36 of the smearing functionality this morning the same error preventing any fitting of sphere to the second page of the two part latex smeared file. Clearly it happens a lot but annoyingly not all the time. Seems like it either does or doesn't. during a session.

[pkienzle]

Looking back at the "unknown escape sequence" warnings, you should be able to find \P, \S, \s, \m in the file. I'm guessing it is a path with backward slashes rather than forward slashes, such as

#line 1 "C:\Program Files\Sasview\sasmodels-data\models\sphere.c"

The generator should be creating these with forward slashes instead. Somebody with a windows box will probably have to debug this. Anyway, it is just a warning, and the line is only needed to make the compiler errors easier to track to lines of code.

The "could not write" is still weird. Before compiling a module it logs what it is doing as you have shown above:

2020-05-28 15:15:06,693 : INFO : root (kerneldll.py:194) :: "C:\Program Files\SasView\tinycc-data\tcc.exe" -shared -rdynamic -Wall C:\Users\PAPERS~1\AppData\Local\Temp\1\sas64_sphere__at4gp1d.c -o C:\Users\paperspace\.sasmodels\compiled_models\sas64_sphere.so

Is there another compile line with the same target in the same session?

If you start with an empty ~/.sasmodels/compiled_models does it create two compile lines?

What are the timestamp on the .so files created in ~/.sasmodels/compiled_models? Are they later than all the timestamps on the files in C:\Program Files\Sasview\sasmodels-data and its subdirectories?

Maybe need to monkeypatch kerneldll so that it outputs a log message whenever a model load is attempted. The following lets me watch the dll file being loaded:

from sasmodels.kerneldll import DllModel
import logging
old = DllModel._load_dll
def new(self):
    logging.info("CDLL %d %s", id(self), self.dllpath)
    return old(self)
DllModel._load_dll = new

Trying this I see that a new DllModel is being created for each fit page, but there should only be one of each. Next place to look is _calculate_Iq from sasview_model, which should be caching the model in the class.

[butlerpd]

testing with 5.0.5 RC2 everythings seems to work fine. But given all the above, it is not clear that the bug is fixed. It may just be that there is a very specific sequence required to hit that failure? I will thus move this to 5.1 but recommend that if no further reports surface before 5.1 release we close this issue at that time?