👌 IMPROVE: Section: Plugins

[mbercx]

General note: Make any changes by opening a PR into the tutorial-2021-intro-week branch. I'm preparing a wiki page with more information on MyST Markdown, but this is still a work in progress.

Update/revise the tutorial content for the Plugins hands-on. I'll let @ltalirz decide if/how he wants to revise the material, but will simply leave some notes below. 🙃

• Although it's nice to have two options, I'm not sure how many participants will be able to do option B, considering this is meant to be an introductory tutorial. It requires figuring out quite a bit by yourself, and looking at different resources. I would propose that we simply use this session to show how to write a plugin with an example.
• It might be nice to consider how to write a data plugin as well?
• The tutorial is now basically just a link to the How-To section on how to write a plugin for an external code. It's fine and efficient to re-use material, but of course we've already talked quite a bit about distinguishing tutorials from how-to's. Make sure that the content is still close to that expected for a tutorial.
• In my enthusiasm for using panels, I split the two into separate modules which are really quite small. 😅 Feel free to adjust this to whatever you think is best.

Note that in the first instance you do not need to test the material, since we'll be setting up a JupyterHub to do this 2 weeks before the event.

Thanks @ltalirz! Note that the above comments are just ideas that popped into my head while quickly reviewing this, I'll leave the final material entirely up to you. :)

[mbercx]

During a meeting on the "writing workflows" section, the idea was raised to also give the participants a full hands-on where they can work on writing their own work chain (or a simple example, e.g. convergence study work chain). Maybe we can offer the participants two options during the "Plugins" session (first session on Thursday):

1. Write your own plugin. I would still recommend the example here.
2. Write your own work chain. They've just had a full day on writing workflows, so hopefully they'll be able to get started with some supervision.

Might be interesting to also invite e.g. @espenfl here to help people that want to write a VASP workchain instead. Also maybe other plugin developers?

[ltalirz]

• Although it's nice to have two options, I'm not sure how many participants will be able to do option B, considering this is meant to be an introductory tutorial. It requires figuring out quite a bit by yourself, and looking at different resources. I would propose that we simply use this session to show how to write a plugin with an example.

In practice, probably 90% of participants picked option A last year. Option B is there for advanced participants in order to be productive and be able to make use of this rare opportunity to talk to aiida-core devs on a specific plugin they are planning to write. I think it makes sense to keep both options as long as their purpose is clearly explained (which I will take care of).

• It might be nice to consider how to write a data plugin as well?

I'll keep it in mind when I revisit the material, but time is limited. It would certainly be good to have a link to materials that explains how to write a data plugin.

• The tutorial is now basically just a link to the How-To section on how to write a plugin for an external code. It's fine and efficient to re-use material, but of course we've already talked quite a bit about distinguishing tutorials from how-to's. Make sure that the content is still close to that expected for a tutorial.

Now that I look back at it, I would say the "How to write a plugin for an external code" section already is more focused on learning than on solving a real-world problem (even without adding extra questions, which I'll try to do). It explains how to wrap the arithmeticadd code, which is a problem nobody has.

If you can open the PR to integrate the tutorials into the documentation web site (no need to involve me; just let me know when it's done - I imagine there will be some discussion where to place them, e.g. under "introduction" or not), I would probably move that section to the tutorials. Also, in that PR please add one sentence to the how-to guides page to orient the reader on the difference wrt the tutorials (e.g. adapted from here).

[mbercx]

I think it makes sense to keep both options as long as their purpose is clearly explained (which I will take care of).

Sure, I agree it makes sense for the tutorial to offer this to more advanced users. As a sidenote: maybe we can organise a separate "hackaton" event for this as well? If we already have a rough idea of when this would happen we could advertise it at the tutorial. :)

I would probably move that section to the tutorials.

How about we just move it into a module in the Plugins section of this tutorials page? If it's more of a tutorial anyways, I don't see the need for a redirect.

I'll keep it in mind when I revisit the material, but time is limited.

Of course, no worries. I think it would be nice to have a similar module for data types as we have for the Code plugin. Perhaps @ sudarshanv01 could help here? 🙃

If you can open the PR to integrate the tutorials into the documentation web site

Happy to do this, but this will of course be after the tutorial. And after we agree on where to place it 😅.

[espenfl]

During a meeting on the "writing workflows" section, the idea was raised to also give the participants a full hands-on where they can work on writing their own work chain (or a simple example, e.g. convergence study work chain). Maybe we can offer the participants two options during the "Plugins" session (first session on Thursday):

1. Write your own plugin. I would still recommend the example here.

2. Write your own work chain. They've just had a full day on writing workflows, so hopefully they'll be able to get started with some supervision.

Might be interesting to also invite e.g. @espenfl here to help people that want to write a VASP workchain instead. Also maybe other plugin developers?

Thanks. I would also like to contribute maybe with something far outside our field. I think having something like this could be useful. This is maybe not for the upcoming tutorial, but maybe the next.

[espenfl]

Now that I look back at it, I would say the "How to write a plugin for an external code" section already is more focused on learning than on solving a real-world problem (even without adding extra questions, which I'll try to do). It explains how to wrap the arithmeticadd code, which is a problem nobody has.

Yes, indeed. Maybe we could figure out a nice useful example that falls intuitively to folks. That way, also the conceptual consumption can be improved. Probably not for this, but we can think of that for the next tutorial we have briefly discussed.

[ltalirz]

Now reporting on my checks of this section.

As for the pointers in the aiida-tutorials (without going to the aiida-core docs yet): this looks all fine and up to date to me. I just have one comment on this:

For this session, we suggest two options depending on your interests and experience – please post in the chat which of the two (A/B) you are going to follow:

That seems a rather tedious way of collecting this information. Can we use a zoom poll instead?

I'm also wondering whether we should be doing something with this information - e.g. we may want to suggest those who want to write their own plugin package to go to a separate zoom breakout room, where we could have 1-2 experienced plugin developers waiting who can help with design questions.

[ltalirz]

As for the plugin howto in the aiida-core docs I see basically two options:

1. keep the current use case of "adding two numbers".
2. move it to use the diff executable as used by the aiida-plugin-cutter

On the pro side, it has been pointed out before that it is confusing that the tutorial uses a different example than the plugin cutter (and the using the plugin cutter would be the logical next step for someone interested in writing a plugin). By moving the howto to use diff as well, we would harmonize the two and automatically get some documentation of the aiida-plugin-cutter.

On the contra side, I see that some other parts of the tutorials (workflows section) make use of the ArithmeticAdd calculation. Of course, making the change is also more work than just going through the tutorial again.

@sudarshanv01 As someone who just went through the process of creating a new plugin (and as someone who would need to work on this section ;-) )- What are your thoughts on this?

[sudarshanv01]

Hi @ltalirz , I guess the diff example is what was the most "useful" when I got started (even though adding two numbers is much simpler). The reason was that diff served as a really nice template to setup the code I was interested in. In general it takes very few changes to get a running example for a completely different code because of the use of SinglefileData, I imagine this holds for many codes. So I guess if the goal of this section was to encourage development of new plugins, diff is a great example.

[mbercx]

That seems a rather tedious way of collecting this information. Can we use a zoom poll instead?

Definitely! I'll prepare a Zoom poll for Group B, @ramirezfranciscof can prepare a Zoom poll for Group A.

I'm also wondering whether we should be doing something with this information - e.g. we may want to suggest those who want to write their own plugin package to go to a separate zoom breakout room, where we could have 1-2 experienced plugin developers waiting who can help with design questions.

That sounds like a good idea, but then we'd need to find plugin developers that are willing to help out.