In the TAB "through-focus scan":

1. Change the input parameters, from lower,upper,step ---to--> lower,upper, N of steps.
2. Then add the field "Step" as read-only, with step = (upper-lower)/N

Also--- the name of the tab could be improved.
3. From "through-focus scan" ---to---> "Focal Scan".

In the TAB: Find Best Focus:

1. Step should be removed,
2. The default number of iterations should be 50

We now have

• Positioning + Orientation + Ignore (+ other computation tweaks if needed)
• Small displacements

We will soon have

• Figure error (I will write a dedicated issue on that)
• we still miss Roughness (I have to fix sutf at LibWiser level)

We have to discuss on how to handle

• plots (in an organic way)

We need to ask Luca

• on broadcasting errors
• on tooltips
• on preinputs

The plan is

1. Do some quick test that Positioning+Displacement is working (we can improve plotting if this is required)
2. Implement Figure error and check it works (it is already done)
3. Implement Roughness

To do 1) I would create a prototype beamline. Here I have one with both V and H elements. I have put into edlettradrive\Examples2020\Milestone\Test Beamlines the file
beamline_layout_fel2_ldm_vh.py (also atteched here as *.txt).

Se you if you prefer to have a "complete" test file, or a "simple" test file + a "sophisticated one".

For the simple one, I would pick up : source+pm2a+slits_h+kb_h+detector_h.

The complete one has mixed H/V elements

Beamline.Append(s)  # source
Beamline.Append(pm2a) # plane mirror (H)
Beamline.Append(presto) # a grating, but in practice it is another plane mirror (H)
Beamline.Append(slits_v) # slits, V
Beamline.Append(slits_h) # slits, H
Beamline.Append(kb_v) # focussing mirror, V
Beamline.Append(kb_h) # focussing mirror, H
Beamline.Append(Detector_h)# detector h
Beamline.Append(Detector_v)# detector v
Beamline.RefreshPositions()

I would start as follow
"TASK"
a) Start in the simplest configuration possible: compute only 1 orientation, considering only source, focussing and detector (other optical elements set to Ignore = True). Then check the other orientation as well. We should get a nice focussed spot.
b) Always with one orientation only, let's add the other optical elements (other otpical elements set to Ignore = False). It should work
c) Let's do it all-toghether!

If it works, everyithin is well piped and we can really go on on more tough ground.

At this level we can do another small test.
Go back to the same condition of a) (a single orientation, no extra optical elements), and let's try to use small displacement on the detector. If you shift it (of 1mm let's say) you should observe variation in the spot size.

This only to do some "fast tests". Extensive testing of the gui will be done by us.

If we do all these simulations at 20 nm, you can safely use 5000 points I would say.

Please, write any comments if you feel I left out something or possibly gave an unprecise reference on what we agreed.

Some refactoring to be done to get the Tools toolbox back...

A widget that can be connected to any point in the beamline (most likely detector) and provide info on:

• distances between OEs and to the source
• names of OEs
• number of calculation points
• other...

I have created a test *.ow files, that we can use as a base for our debug.

I have put it on seafile, in the "Examples 2020" Folder.
The path is
\Examples 2020\OASYS Tests\test_wiser_margot.ows
Do you see it?
In the next issues I will refer to it.

I have wrapped a little bit of code on that, so we can easily compare oasyswiser and libwiser. Python scripts will show you some plot (yes, it is possible even from within Oasys, which is great).

CAVEAT:
They contain absolute path (see screenshot), so you might change them.

If you know how to answer to my email (where I ask how to transport variables from one python code to another), we can make a unik python script distributing boring stuff (such as absolute paths) to the other scripts.

Feel free to change the file, but save it with a new name. I will do the same.

You can close this issue, if you have no comments.

Use built-in Oasys unit conversion so that the workspace setting can correctly work with Wiser widgets.

This now results in an error... Future warnings have to be treated seriously.

Modify do_wise_calculation (line 320 in ow_optical_element.py) so it is more modular.

In the parameters of the gaussian source, we should add "M^2" (best typed with 2 as superscript).
Default value = 1
It is wired directly to M2
def __init__(self, Lambda, Waist0, M2 = 1, XYOrigin=[0,0], AnglePropagation=0, **kwargs):

Reading the script in "LtpJavaMode" or with "x, Height" does not work.

I have put two scripts containing the right results.

BEWARE: they contained hardcoded paths. So just change them. We should do a unique python script delivering the main path to all the others (for debug purposes).

Independently on Issue #44, the save/load command does not work with the figure error.
When loading a *.ow file, you will always find the default value

I would like to know more on how the save/load works, so that we both have an eye on that. Perhaps on next meeting would you share the code?

I have updated LibWiser.

I think there version in oasys is out of date (see issue #42), and we need to use the new version.

If you do this, please have a quick look (on "Margot" test file) that main things are still ok.

I did not do big changes, but you never know...

I think the last-appended O. E. gets correctly positioned, but somehow its position is wrongly reported by __disp__ each time. This has to be investigated. This does not happen when scripting, only in the GUI.
When appending the next O. E., the distance for the previous gets corrected.

Now Positioning directives (PD) in OASYS allow "full control" to parameters ReferTo, What, Where. I think this is too complicated (not all the combinations are possible for all the optical elements), and it shall be improved.

A solution is define the PD we really need and prepare almost-locked combinations.

Some mostly used PD are:

-"Measure distance from Source" / "Set downstream of the source"
(ReferTo = Source, What = centre, Where = centre, SameOrientation = Anye?)
Label: "Reference Element" ---> Source.Name
Fields: "Distance" ---> linked to Distance

commonly applied to: any optical element, especially focussing mirrors

-"Measure distance from previous optical element" / "Set downstream"
(ReferTo = upstream, What = centre, Where = centre, SameOrientation = false)
Label: "Reference Element" ---> (GetParent(self, SameOrientation=False, OnlyReference=True)).Name
Fields: "Distance" ---> linked to Distance

commonly applied to: any optical element
Note: it refers to ANY orientation => the orientation of the optical element shall be clear in the Label field?

-"Autofocus" /"Set in the focus"
(ReferTo = upstream, What = centre, Where = downstream focus, SameOrientation = ?)
Label: "Reference Element" ---> print the name of the reference focussing mirror
Fields: "Defocus" ----> linked to Distance
this is used for instance with detectors,

• Others...?

Autofocus does not work in GUI

Find a way to display Reference O. E. you're referring to when positioning a new O. E.
This depends on:

• selected Mode

• Orientation

For Michele:

• Check/polish toolib functions to use for loading the figure error, so that Aljosa has easier life in implementation.

-For Aljosa and Michele:
Discuss the following format (we have already talked about that, I am just putting it to written form). Discuss which function to use and where (I guess something in wofrywiser).

It displays correctly, but lacks some descriptive information.

We have some spare flags to wire to the gui.

• ComputationSettings.Ignore = True/False => Maybe in Computing tab?
• Else?

Correctly implement orientation of optical element. Probably it will be located in "Position" tab.

Hi, I try this (new way) to keep track of what we say in meetings. Let's see how it evolve or if it is just extra cluttering.
It is an improvement of the "MEMORANDUM Issue".

There is some bug with slits in the GUI...

In order to comply with the rest of the add-ons, rename the repository and the package to:

OASYS1-Wiser

Multiprocessing is currently (OASYS1-WISE2) taken care of by multiprocessing package. The GUI settings are located in Calculation settings -> Parallel computing

This will go away, as the new kernel uses numba to spread over the multi CPUs and at the same time uses a JIT (just-in-time) compiler which pre-compiles code with LLVM. Even if using single-core calculation, this should be faster than using native Python code with multiprocessing (this claim is untested).

To do:

• Make the workspace

• Test with single orientation

• Test with multiple orientations

• Check if calculation runs

• Check if results are correct

Beamline.Append(s)  # source
Beamline.Append(pm2a) # plane mirror (H)
Beamline.Append(presto) # a grating, but in practice it is another plane mirror (H)
Beamline.Append(slits_v) # slits, V
Beamline.Append(slits_h) # slits, H
Beamline.Append(kb_v) # focussing mirror, V
Beamline.Append(kb_h) # focussing mirror, H
Beamline.Append(Detector_h)# detector h
Beamline.Append(Detector_v)# detector v
Beamline.RefreshPositions()

M2 is working now
This means that by changing M2, the width of the Gaussian intensity changes on a detector

However the intensity plotted in the source widget is wrong and does not respond to any parameter settings.
Probably this is due to imperfect design by Luca.

How to solve it
Analytic sources does not really contain a propagated intensity to plot (unlike other numerical elements).
The previewed plot is just the gaussian function evaluated on a certain x axis at a certain distance z.

Option 1 the easiest thing could be add two fields used for visualization only "x axis total length" and "z".
Something like that

Option 2
Compute the intensity with

• z = GaussianSource.RayleighRange(...) and
• x = 4 * GaussianSource.Fwhm(z)
  then write in the plot a meaningful title like "Intensity at the Rayleigh length = x.xm" (number properly formatted).

just choose the faster one

• test
• implement if not working

In at least one condition, when loading the files OASYS fails in restoring the values stored in the *.ows file.

• I do not know if this concern WISER only, or other packages as well
• I would not know how to replicate the problem.

Speculation: it happened just after updating OASYS1-wiser. Could the two thing be related?

For this reason, I have included the parameters I used as acomment in the text.

Action suggested:

• keep an eye on values while using the *.fow file
• keep an eye on values at the next update of oasys-wiser.
• any idea is welcome :)

Formatting numbers is a pain-in-the ass, especially while plotting.

We have to ensure that number formatting is visually acceptable:

1. when displaying single numbers
   

2. In plots, expecially on the X axis.

How:

1. Let's create an interface function in oasys1-wiser that wraps GetEngNumberSI. Example: smart_format_number
   It should also contain a 'UnitLetter' (m for meters, C for Coulombs, etc).
   It could contain a place holder for "DecimalDigits", that raises a NonImplementedError.

2. There are a lot of considerations to do.

• A good solution is to force scientific representation for both axes. This is done by means of plt.ticklabel_format(axis="x", style="sci", scilimits=(0,0)) (see example below)
• An even better solution is to use SI formatting, e.g. 0.001 => 1m (1 milli-),
  (see the code below, generating those figures)

I would do an interface function (e.g. smart_format_plot) that for now implements the good method, leaving the "even better" one for someone else.

Possible structure

def smart_format_plot(plot_handle, 
x_label ='', 
x_unit = '',
y_label = '',
y_unit = '',
title =''
)

labels and units are composed as "%s [%s]" %(x_label, x_unit).

See you what's the best compared with the existing code.

Example code

# -*- coding: utf-8 -*-
"""
Created on Thu Mar 18 13:59:23 2021

@author: Mike
"""

#%%
import LibWiser.Units as Units
import numpy as np 
from  LibWiser.EasyGo import *


a = 1e-5
x = np.linspace(-a, a, 1000)
y = x**3
XUnitLetter = 'C' # Coulomb
XUnitName = 'Charge'
XSmartFormat = True


YUnitLetter = 'A'
YUnitName = 'Current'
YSmartFormat = True


plt.figure(1)
plot(x,y)
plt.title('afwul figure')

#%%
plt.figure(2)

plot(x,y)
plt.ticklabel_format(axis="x", style="sci", scilimits=(0,0))
plt.ticklabel_format(axis="y", style="sci", scilimits=(0,0))

plt.xlabel('%s [%s]' %(XUnitName, XUnitLetter))
plt.ylabel('%s [%s]' %(YUnitName, YUnitLetter))
plt.title('good figure')


#%%
plt.figure(3)
if XSmartFormat:
	XToUse, XScaleLetter = Units.GetAxisSI(x)
else:
	XToUse = x
	XScaleLetter = ''
	


YToUse = y
	
plot(XToUse, YToUse)

plt.xlabel('%s [%s%s]' %(XUnitName, XScaleLetter, XUnitLetter))
plt.ylabel('%s [%s]' %(YUnitName, YUnitLetter))
plt.title('even better figure: we have unit letters on x')

#%%
plt.figure(4)
if XSmartFormat:
	XToUse, XScaleLetter = Units.GetAxisSI(x)
else:
	XToUse = x
	XScaleLetter = ''
	


if YSmartFormat:
	YToUse, YScaleLetter = Units.GetAxisSI(y)
else:
	YToUse = y
	XScaleLetter = ''
	
plot(XToUse, YToUse)

plt.xlabel('%s [%s%s]' %(XUnitName, XScaleLetter, XUnitLetter))
plt.ylabel('%s [%s%s]' %(YUnitName, YScaleLetter, YUnitLetter))
plt.title('we overdid: we have wrong scale Letter on y')

Slider does not work, have to fix it.

Handle all the errors using syntax similar to this:

try: and except: constructs

Part 1 of 2
We can leverage on ToolLib.CommonPlots for plotting data in a uniform way.
Some example:

This one is for plotting the "last figure error used in computation" (I use it to be sure that WISEr used the figure error I wanted him to use)
LibWiser.ToolLib.CommonPlots.FigureErrorUsed(kb)

This one is to plot the intensity of a certain optical element
LibWiser.ToolLib.CommonPlots.IntensityAtOpticalElement(kb)

The function looks like this:

It plots to an external figure. I do not know if the output can be easily redirected to a GUI figure. If not we have two options:

• re write proper code in WofryWiser

• improve code in LibWiser

Part 2 of 2
In general, in plot we should avoid ugly formatting, such as "0.00005". The modyke Units that can (does not have to) be useful.
Example
x = 1e-7
b = Units.EngUnit(x)
b.unit = 'm'
b

100nm
b.eng_num
100n
Unit.GetEngLetter(x)
'n'

Define the correct way to display x axis in Find best focus calculation. Now it is wrong! It would be best if function Foundation.FindFocus would return S as well.

Here I report some (apparently) weird behaviors I caught while writing the code.

In OpticsNumerical

Left is wrong, right is ok

Yellow = rx = ok
grey = sx = wrong

I have no ideas (perhaps try is very strict and it catches warning, too?).

Action: I revert to RX version.

What we did

To do

Features needed:

• Propagation

• Positioning

• Orientation

• Figure error

All this to be tested with a simple OWS with source, slit, plane mirror, elliptic mirror and detector of both orientations.

It happened to me to waste a lot of time in a script because I got this error (LibWiser)

the reason was that I had a beamline with all HORIZONTAL optical elements, and I changed the orientation of the last two (focussing mirror and detector) but the source was not set to ISOTROPIC or ANY.

We could
a) throw a proper warning in LibWiser ( Something like "No Optical Element with the same orientation found. Check Source orientation").
b) ensure that the source is alway isotropic/any in the GUI ?

Rewire:

• source
• plane mirror
• elliptical mirror
• detector

Connection path (-- means to do): OasysWiser -- WofryWiser -> LibWiser

It works for me, which probably means that there oasys is using an outdated version of LibWiser.

I have pulled the new one to master (rememember that master2 shall never be used)

If I run the script of the python script widget "test gaussian m2" with my Local version of LibWiser, I get:

(I have run the script twice, changing M2).

If run the widget, I always get this (no matter of M2 value)

I guess that if that if LibWiser is updated, everything will be fine.

We have encountered problems with the units conversion.

An option could be eliminate it (but can we do that? Or is it something that Luca should do?)

Waiting more info from Michele:
if we use meters, is everything ok, or we still have problems?

I need some input to grow faster on the data storage stuff. Now I store data as

lw.tl.FileIO.SaveToH5(FileOut,
						[
					  ('ParameterScan/X',XAxis),
					  ('ParameterScan/Y',YAxis),
					  ('ParameterScan/Z',ZCollection),
					  ('ParameterScan/XInfo', XInfo),
					  ('ParameterScan/YInfo', YInfo),
					  ('ParameterScan/ZInfo', ZInfo)],
					  FileAttributes,
					  Mode = 'w')

Each XInfo (which is another data strcuture, o a "Group" as it is called in hdf) looks like a good candidate for becoming "attributes" to be attached to "X", since "XInfo" is:

Label:  $\vartheta$
Name:   Angle
Unit:   rad
VisualizationFactor:    1000000.0
VisualizationPrefix:    u

I could not easily find out how to do that. If can ask someone, I can polish the data storage system.
For the moment, I only can store generic attributes (the FileAttributes, which is a dictionary).

FYI, the previous piece of code comes from
"[elettra.drive]\Examples 2020\Milestones\Test Purosangue Manipulation Script\PurosangueKernel_WiserInvestigator_00_Locked.py"

Topic1
This message must not been displayed when the user press apply onto a new source.

Exception                                     Traceback (most recent call last):
  File "C:\Users\Mike\Miniconda3\lib\site-packages\orangecontrib\OasysWiser\widgets\light_sources\ow_gaussian_source_1d.py", line 163, in do_wiser_beamline
    raise Exception("Nothing to apply. Source is the first element of the beamline.")
Exception: Nothing to apply. Source is the first element of the beamline.

Topic2

"apply" must initialize the LibWiser.OpticalElement. If it is not like that, then it is useless.
Expectation:
I drop an optical element A
I change its name: "A2"
I drop an optical element B
I link A to B
I click apply to B (or both A and B)
I expect to see that the "reference" in B has the correct name "A2".

If this is not possible, or too complicated at this level of the development, or against the logic of the chain-of-responsibility, we should give up the idea of the "apply button". And focus only to make the "compute" and "compute all" working.

We can just start with "hiding" the button without deleting the code

Comments on that?

The detector shall allow the 3 following operations:

1. Compute the field in the nominal position (or corrected with SmallDisplacement) => Single computation. We call .ComputeField.
2. Compute the field in the best focus (not existing yet, we should call Foundation.FindFocus function)
3. Perform a scan of the field through the focus (already existing, calls Foundation.FocusSweep)

t.b.d

Handle all the errors using syntax similar to this:

try: and except: constructs

Implement different PD defaults for different O. E.:

1. Source: absolute (X, Y = 0)

2. O. E.: distance from source or O. E.

3. Detector: autofocus

Refactor all the remaining things from WISE2 to Wiser

We know the formatting of plots is not yet uniform across the (wiser)GUI, especially in the plots.

However we could start testing "SmartFormatter" only on some plots, the decide if/when to extend it.

Example, in the plot

we could try

Advice
Since Units.SmartiFormatter is a LibWiser function, it would be better to create a OasysWiser function, so that the code of OasysWiser still interact with himself only.

Hey,

I saw you have been changing some things around the figure error handling in Foundation. It seems that something doesn't work with the latest LibWiser.

I am getting this error when using ldm-kbh/Scan_Motor5_55_res.dat file with ELETTRA-LTP-JAVA1 setting. I am almost 100% that this is due to an upgrade in LibWiser, since the propagation works normally without figure error and I saw there were some changes recently.

Cheers,
Aljosa

The chain of responsibility stopped working.
We have to investigate that AASAP

General question:
which version of LibWiser does Oasys use? Does it fish the info from GIT repository, or is there an intermediate step, where a "push" from GIT to another space is required? [I guess it is the second]

Placeholder for numerical source issue... @maltissimo @capitanevs