Save/Load, again => Defaulting values

[capitanevs]

We still have the Save/Load issue.

Because of its persistence, I will promote it to the nastiest bug ever, and the one with the highest priority.

What doest it happen
At a certain point, the values stored in *.ows file are defaulted.

How do I see it?
I have created a test workspace long time ago (Margot_3), which I marked as READONLY, (an which is read only on my laptop). This ensure that I have never overwritten the values since the file creation. The "right" values are written in ows file as comment.

What shall we do?

• In principle, if we reverted to a older version, we should be able to read this ows file in the right way (or no?)
• It would really be interesting to understand when values are defaulted (that's hard. Mail to Luca? Mail to Orange authors?)
• Find a way to reproduce the bug...
• Discuss... .what do you think?

[aljosahafner]

I suggest a mail to Luca. He probably knows ...

[capitanevs]

Ok. Before doing that, I would try as follows:

• you check that you also experience the same problem with the attached ows
• can you try to see if with a different OASYS/LibWiser installation you can fix the problem? That would be of real help. (I guess the problem is in OASYSWISER).

I'll post an old answer of Luca here, just as common starting point.

-------- Messaggio Inoltrato --------

Oggetto:	Re: OASYS/ORANGE load/save
Wed, 17 Mar 2021 15:52:12 +0000
Rebuffi, Luca [email protected]
Michele Manfredda [email protected]
Aljosa Hafner [email protected]

Dear All,

The load/save is based on the "pickle" package,
that belongs to the kernel of python. We have experienced issues in the
past, especially with some releases of Anaconda.
Sometimes, the
pickle load failed when the file was saved in miniconda and opened in
standard python or with a different version on miniconda. The result is
the appearance of all default values in the input fields of the widgets.
This
is the main reason why we froze the miniconda version in the
installation script. When a problem like this happens, you should not
save the ows again, in order to not loose the original content, and try
to open it with a different installation of OASYS.
Anyway, this is the website of Orange: https://orangedatamining.com

Be
aware that OASYS is relying on a special release of Orange, dated 2013.
I did several modifications and upgrades, but it is no more aligned to
the "original" one.
The manpower needed to realign to the "original"
version (several weeks...) is not justified, especially considering the
risks related to rewriting the kernel of a software.

In case you
need my help, I need far more detailed information. I hope you can
identify the cause soon or find a reproducible pattern that shows the
error.

Best,

Luca Rebuffi, Ph.D.

[capitanevs]

Note:
on MM laptopt, the recent update of OASYS was not installed (and the problem still persisted)

[capitanevs]

MARGOT TEST OWS attached here

Rename from .MOV to .OWS to make it work :-)**

test_margot_03_READONLY.LOG

[aljosahafner]

It works in my installation, file: test_wiser_margot_correct2_READONLY.ows

[capitanevs]

It works in my installation, file: test_wiser_margot_correct2_READONLY.ows

please be sure that we all use the same file.
The correct one is test_margot_03_READONLY.ows

[aljosahafner]

You're right, that one gets reset. Maybe there is some problem with Positioning directives, saving with a different one to the default?

[capitanevs]

TEST BY MARCO ZANGRANDO

file: test_margot_03_READONLY.ows
OS: (macOS) Catalina

RESULT: BAD :-(, values are defaulted (e.g. elliptical mirror F1=98)

[capitanevs]

You're right, that one gets reset. Maybe there is some problem with Positioning directives, saving with a different one to the default?

I do not understand exactly what you mean:-)

WISER has no default values, but oasys widget have. In addition, this is not a matter of PositioningDirectives only, but of all the attributes (F1 and F2 are sent to init, not to PositionindDirectives). So the problem is somewhere in OASYS, I would say.

If you have some idea for a test for this involving LibWiser, I can do a counterproof.

In the meanwhile, since we have the issue an all the platforms, we need to roll back OASYS-Wiser (of 1,2,3 versions?) and see whether we can get the right values back.

Can you possibly handle this?

[aljosahafner]

There is a problem with the pickle module for this specific file, that's why it happens. It's not a problem of LibWiser, but ows files of course. You can always revert the version by doing:
pip install oasys1-oasyswiser==version_no

[aljosahafner]

So, I have tried LOTS of combination and couldn't manage to run the file: OASYS Tests/Test Margot/test_margot_03_READONLY.ows
The following combinations don't work (don't open the file with correct numbers)

Maybe we need to try some other strategy...

[aljosahafner]

My OS File browser says the file test_margot_03_READONLY.ows was last modified on 26. 8. 2021, there haven't been that many versions of OASYS1-oasyswiser and LibWiser since then, so at least the last one should be able to open it.

[capitanevs]

That's VERY interesting.

Premise:
I clearly made some mistake in the process.
test_margot_03_READONLY.ows is not really "read only" on my laptopt (wtf?). I sweared it was, but it is not.
This means that there might have been a wrong saving operation on 26.8.2021, of which we still do not understand the causes (for sure I have never put the default values, for all the widgets, manually).
But there is some partially good news:

I have a backup file in my "\old" folder

test_margot_correct3_READONLY.ows => is still readonly, and it was last modified on 18.03.2021.

test_margot_03_READONLY.ows => wrong numbers
Itest_margot_correct3_READONLY.ows => right numbers

Conclusion:
Reading "seems" to work.
Still do not know why in "margot_03" values are defaulted.

What to do now?
All this is quite frustrating,
We could: change the default values of the elliptical mirror focals F1, F2 to 0.
Then cast an error message

If F1==0 or F2==0 then
   errorMessage("Focal lengths of the elliptical mirror can not be 0. Please check them"

This is just a different strategy to monitor the behavior of this thing: if it occurs, you will realize it as easily as me (4 eyes are better than 2).

The other thing we can do is write an email to Janes&co and say: "Hey, sometimes our values are defaulted, but we do not know when and why. There is something we can do, like adding a warning somewhere in OASys"?

What you think of all this?

[aljosahafner]

Ok, I can read the one in old fine with the latest versions, values are not defaulted.

[capitanevs]

Ok, good. This is what I see in my \old\ folder

What do you think about setting F2 of the elliptic mirror to 0 and then cast the error message?

[aljosahafner]

That means that always when you add an optical element you get this error?

[capitanevs]

Sorry, I was unclear.

The idea is: " if a certain value is 0 when you launch the computation, then cast the error message", not "when you drop an optical element" :-)

[capitanevs]

This is new...

-I create a new file ("untitled.ows"), i use gaussian source + elliptical mirror + detector.
-I change "Displacement" in the source (and see nothing, which is another issue). "Longitudinal" is set to -15
-I close the ows, without saving.
-I open another workspace (Wiser Snippets.ows)
-I open the source and the "Longitudinal" displacement is still at -15...Also the values of the mirror are the same of the "untitled.ows"

This stuff is quite unpredictable

[capitanevs]

Note: I DID NOT close oasys, I just opened "wiser Snippets.ows" in the same session

[capitanevs]

TO DO

• I have changed LibWiser in this way

• You should change the default values of the elliptical mirror, say: F1 = 0, F2 = 0

Then everything should gear up automatically.

[capitanevs]

Did new test: on new default falues F1 and F2 of elliptical mirror:

case 1
-open oasys
-deploy an elliptical mirror widget
-double click
-F1 = 0, F2 = 0
=> As (I) expected

case 1b)
-the same as 1)

• change values of F1 and F2
• create a second elliptical mirror (em2)
• F1 and F2 of "em2" are equal to the last inserted ones, that is F1 and F2 of "em1)
  => As I did not expect, but It is an Oasys Feature, not a Bug (the same happens with any of SRW widget)

we still have to check what is gonna happen when defaulting occurs because "load ows" fails