more problems with math in plugins (Trac #1173)

[butlerpd]

while testing a pull request downloaded from the jenkins build thereof, the old

unsupported operand type(s) for *:'NoneType' and 'float'

reared its head again. Other plugins had no problems. Further investigation shows that the exact same function generated from a 4.2 "create model" works while the failing function was created in 4.1.2? However, after editing so that code wise they look identical to me the "older" version continues to fail on the math while the new one does not. I attach the two files.

Is this due to sasmodels infrastructure running these two identical codes differently with one path being wrong? i.e. having a bug not present in the way the files identified as new don't?

Our release notes say we support old style models am listing this as critical to 4.2 release. At the very least we need to correct the release notes if we cannot resolve this issue.

Migrated from http://trac.sasview.org/ticket/1173

{
    "status": "closed",
    "changetime": "2018-09-25T23:15:49",
    "_ts": "2018-09-25 23:15:49.928933+00:00",
    "description": "while testing a pull request downloaded from the jenkins build thereof, the old \n{{{\nunsupported operand type(s) for *:'NoneType' and 'float'\n}}}\nreared its head again. Other plugins had no problems.  Further investigation shows that the exact same function generated from a 4.2 \"create model\" works while the failing function was created in 4.1.2?  However, after editing so that code wise they look identical to me the \"older\" version continues to fail on the math while the new one does not.  I attach the two files.\n\nIs this due to sasmodels infrastructure running these two identical codes differently with one path being wrong? i.e. having a bug not present in the way the files identified as new don't?\n\nOur release notes say we support old style models am listing this as critical to 4.2 release.  At the very least we need to correct the release notes if we cannot resolve this issue.",
    "reporter": "butler",
    "cc": "",
    "resolution": "fixed",
    "workpackage": "McSAS Integration Project",
    "time": "2018-09-09T19:17:21",
    "component": "SasView",
    "summary": "more problems with math in plugins",
    "priority": "critical",
    "keywords": "",
    "milestone": "SasView 4.2.0",
    "owner": "pkienzle",
    "type": "defect"
}

[butlerpd]

Trac update at 2018/09/09 19:18:45:

• butler changed attachment from "" to "L3_Porcar_et_al.py"
• butler commented:

failing older version edited to be "identical" to new version

[butlerpd]

Trac update at 2018/09/09 19:19:25:

• butler changed attachment from "" to "L3_Porcar_et_alNEW.py"
• butler commented:

New version which runs without problem

[butlerpd]

Trac update at 2018/09/09 19:20:19:

• butler changed owner from "" to "pkienzle"
• butler changed status from "new" to "assigned"

[pkienzle]

Trac update at 2018/09/11 22:03:13: pkienzle commented:

See #1183.

[pkienzle]

Trac update at 2018/09/11 22:12:36: pkienzle commented:

It seems to work with master for sasview and sasmodels (2016-09-11) on mac started with run.py.

Please give the steps required to reproduce.

[butlerpd]

Trac update at 2018/09/12 00:18:00: butler commented:

Interesting .... by "works with master" I assume you mean on your local development environment? If so this may indicate the problem is with the build machine. I should test with the latest development build (rather than the PR build).

[butlerpd]

Trac update at 2018/09/16 19:50:17:

• butler changed attachment from "" to "Porcar_Pq_Sq.py"
• butler commented:

offending multiply model

[butlerpd]

Trac update at 2018/09/16 19:51:33: butler commented:

Hummm.... so it seems the problem was more subtle and involves the presence of a multiply model multiplying the "offending" model by a plugin SQ. Removing the pyc for that multiply model does not help. So why does the mere existence of another plugin affect in any way whether the first plugin can pull in the math? I attach the multiply model.

[pkienzle]

Trac update at 2018/09/17 17:05:37: pkienzle commented:

Because the model is written with load_model_info(), this does a reload on the parts, L3_Porcar_et_al and L3_Sq, and it is the reload which is causing problems with the namespace for the module.

This could be resolved by throwing a cache in sasmodels.custom which checks the timestamp on the file before reloading the module. This should be a relatively small fix suitable for 4.2, and at least allow L3_Porcar_Sq_Pq to load.

There will still be problems: if Pq or Sq are edited and reloaded, then Porcar_Pq_Sq will be break. This one is harder to resolve since the timestamp on Porcar_Pq_Sq will not have changed, and so Sasview will not know that it needs to be reloaded. I'm guessing for a proper fix for this we will have to maintain a tree of dependencies, and force a reload of all those that are affected by the change of a timestamp. This is a 4.3 fix.

[butlerpd]

Trac update at 2018/09/17 17:21:32: butler commented:

So if I understand what is happening now, there is the same reload problem causing math to be cleared out as before but in a more subtle way? If true that would mean that:

I create plugin model A and it works
I create plugin model B and it works
etc
and all is happy

NOW if I do a sum/multiply model that uses A, for example
NewModel1 = A * hard_sphere or even
NewModel2 = A + B

all of a sudden Models A and B no longer work?!

I will try to test this. If true it needs fixing in 4.2 if at all possible. Maybe the "relatively small fix suitable for 4.2" would do the trick?

[sasview-bot]

Trac update at 2018/09/25 23:15:49:

• GitHub [email protected] commented:

In changeset dd16e070c2ce8fc5bba6a4c0ff93205310f52888:

#!CommitTicketReference repository="sasmodels" revision="dd16e070c2ce8fc5bba6a4c0ff93205310f52888"
Merge pull request #308 from SasView/ticket-1173-cache-loadinfo

Ticket 1173: cache load info

Closes #1209

• GitHub [email protected] changed resolution from "" to "fixed"
• GitHub [email protected] changed status from "assigned" to "closed"