Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libpyvinyl next steps #70

Closed
CFGrote opened this issue Oct 29, 2021 · 1 comment
Closed

libpyvinyl next steps #70

CFGrote opened this issue Oct 29, 2021 · 1 comment
Assignees

Comments

@CFGrote
Copy link
Contributor

CFGrote commented Oct 29, 2021

Extend/edit libpyvinyl such that it accomodates the needs of

  • SIMEX
  • McStasScript
  • Shadow3
    @srio has made a number of suggestions that I attach here:

I wanted to apply it to Shadow and my first trial was very complex. The main reason is that I had to copy all the calculator parameters in the new rigid structure. I forked the libpyvinyl repository and made some test (limited only to shadow3 sources): https://github.com/srio/libpyvinyl/blob/master/tests/Shadow3Calculator.py

Then, I made another experiment. I believe that we should incorporate the native parameters in our parameters, in a very generic way, and avoid copying all the items. I propose to define only a very few basic base/abstract classes with the list of the mandatory methods to be implemented, and then make another top layer to implement the particular calculator. My proposition to the generic classes is:

https://github.com/srio/libpyvinyl/blob/master/libpyvinyl/VyBase.py

My implementation of the shadow3 binding to vinyl is: https://github.com/srio/libpyvinyl/blob/master/libpyvinyl/VyShadow3.py

you see that the binding inheritates the 3 main classes and it interfaces them to the shadow3 methods and objects, but does not create a duplicated list of parameters. The code is simple. Creating scripts with Vinyl-shadow3 is as simple as in the native format (you can see it in the example included). The main work is then concentrate in adequate the i/o (json, nexus, h5 etc) to be made at the level of the binding. However, we can provide basic tools at the level of the abstract classes (e.g., dict to {json,h5} and viceversa).

I believe that most of Manuel's suggestions are already present but maybe lack proper documentation and/or usage examples.

@shervin86
Copy link

shervin86 commented Dec 14, 2021

I would remove this issue. It is a collected duplicate of:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants