jerome-lma / oscar Goto Github PK

It would be nice to add some output arguments to functions like Get_info.m that these functions can be easily used in external scripts/functions. Otherwise everyone who uses the oscar code would duplicate such code...

In my case, it is useful to shift the mirror profile by an arbitrary distance. This feature could be easily implemented at the step of creating the mirror surface. In the branch "shifting" of my fork, the code is shown how you could implement it.

As I work with mirror imprinted on fibers with dimensions in microns, the MATLAB "polyfit" function gives the following Error/Warning: Warning: Polynomial is badly conditioned. Add points with distinct X values, reduce the degree of the polynomial, or try centering and scaling as described in HELP POLYFIT.
You can fix this warning with the scaling feature of the "polyfit" function. A possible code is shown in the branch "fitting-tiny-e-fields" of my fork.

Hello,

I am attempting to learn OSCAR, and as such I expect my issues are more due to my lack of familiarity with the program than with the code itself. When running these two examples (the latest version published on Github), I receive an error stating the following:

Unrecognized method, property, or field 'I_array' for class 'Cavity1'

Error in Cavity_Resonance_Phase (line 12)
Field_in = Change_E_n(Cin.Laser_in,Cin.I_array(1).n2);

I am currently using the latest version versions of Cavity_Resonance_Phase and Change_E_n and Cavity1 available on Github. What is the property of Cavity1 that is incompatible with Cavity_Resonance_Phase? I have successfully run the 4 mirror examples (fold and ring) that use CavityN rather than Cavity1. Should I just use CavityN instead?

Thank you!
Nathaniel Nye

Hi,

I experienced Memory limitations of the GPU, when using the method Declare_on_GPU in the branch next_release.

As pointed out in my GPU-Issue #1, I was able to calculate the FSR-Scan for up to 512x512 EFields. However, when preallocating GPU-Memory with Declare_on_GPU inside of the Cavity1 class, there is not sufficient memory left for high resolution scans.

I think, it would make sense to work with flags, as you already declared in the Cavity1 class:

And then simply convert the Arrays to GPU-Arrays during runtime on demand. I am pretty sure, that we will not lose that much performance with that and can also calculate FSR-Scans with higher resolutions.

I was wondering, if we should directly calculate the resonance position instead of calling an error as done here:

and here:

Any thoughts on this?

Hello,
I just started parallelizing OSCAR on the GPU. First tests with the simple cavity-scan, already showed pretty impressive results. The implementation can be seen at 6c94c74. It simply consists of a big multidimensional matrix multiplication, that takes place on the GPU. The current progress will take place on the gpu_support branch. Contributions are welcome and can be communicated here with me (@nilsmelchert) and @Jerome-LMA.

For the tests shown below, I ran the example script Example_cavity_FSR_scan.m with different resolutions:

• 64x64

• 128x128

• 256x256

• 512x512

The following hardware was used:

• GPU: NVIDIA GTX 1080

• CPU: i5-8600K (6-Cores)