Overhauling Zapdos

[Shane Keniley]

Hey all,

I'd just like to open a discussion about possibly upgrading Zapdos...and by upgrading I mean completely overhauling its user interface.

I had the opportunity to cover a few lectures for my advisor's computational plasma physics course this semester, during which I showed them how to use Zapdos and Crane to solve simple plasma chemistry and DC glow problems. The most common issue was just how big the input file is and how much stuff you just need to know how to add seemingly off the top of your head. Lots of pieces of the input file just aren't clear to new users. Obviously any new software includes a learning curve, but I think it's way harder than it should be to get just a simple DC glow simulation running. For example, the boundary condition names - there is no way to just know those names off the top of your head. You need to dig into the source code a bit to figure those out. Right now users need to rely on preexisting input files, the user guide (thanks Corey!), or just posting questions here to figure out how to use the code, and even then you sometimes need to open the .C files to see which input parameters are necessary.

I think we're getting to the point where we can start making this code a little more like COMSOL -- e.g. we can create Actions that users can intuitively grasp without requiring them to search for all these different input parameters that seem so random. Right now I'm thinking of adding a few different Actions, essentially mirroring COMSOL's different "interfaces" in the plasma module: 

1. ElectronTransport
   • Input: transport coefficients file, initial conditions,
   • electron and mean electron energy drift-diffusion equations
   • electron Materials (transport properties, mass, charge, etc.)
2. HeavySpeciesTransport
   • Input: species name, mass, charge, initial condition, and (for now) transport coefficient(s)
   • Ion and Neutral drift-diffusion equations 
   • Diffusion and mobility materials -- eventually these can be made to be temperature dependent and mixture averaged, making them quite complicated
   • Poisson equation
   • Boundary conditions (boundary_conditions = 'Hagelaar', 'Lymberopoulos', ...)
   • Basically similar to Corey's DriftDiffusionAction, but each species will be added one by one. I split electrons and heavy species because they require different materials and BCs. 
3. Reactions (Crane - kind of already in place but it could always use some improvement!)
4. Interfaces
   • This is just an idea. Right now we nominally have two types of interfaces: dielectric (e.g. surface charge accumulation) and water (e.g. electron transport, heavy species solvation -- I'm working on a PR for the latter right now)
   • "type = Dielectric" would add surface charge accumulation and the electric field interface kernel automatically
   • "type = Water" would add electron and heavy species solvation across the specified interface automatically

This is just a very rough outline and it obviously needs a lot of work, both on the planning side and on the coding side. Using Actions this aggressively would also cover up a lot of the actual mathematics being employed, so we would need a very in depth user guide explicitly describing each option and the equation(s) those options add. (Basically like Corey's user guide, just updated to cover the individual interfaces we add.)

I think reformulating the code in this way would help users get into using Zapdos much more quickly. Right now even adding a single species is a daunting task - even if you use the DriftDiffusionAction you still need to know the appropriate material to add, the right boundary conditions, and any interface kernels that are appropriate. Using Actions would make all of this automatic. I understand that one of the good things about MOOSE apps is that you really need to understand the underlying PDEs and I appreciate that, but I think there's a way to both understand the PDEs and make the input files easier to write - it doesn't need to be one or the other. The user guide and lots of examples would help people figure out how the terms are added, what they mean, and how to modify them if necessary. 

What do you all think? This is a very long term goal here -- I'm not suggesting we all drop everything and start writing Actions immediately.  I was just thinking that we need to take the user interface seriously if we want this to be an open source alternative to all the commercial plasma simulation tools out there. The best way to design this kind of user interface is definitely up for debate.

-Shane

(Sorry not sorry for the wall of text.  :)  )

[Steven Shannon]

I think anything to simplify the interface without taking away any flexibility would be great.  I agree that starting up can be a steep learning curve.

--
You received this message because you are subscribed to the Google Groups "zapdos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zapdos-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zapdos-users/04a427d5-2f73-483e-99d7-f718b6ca4ea2n%40googlegroups.com.

[Alexander Lindsay]

This doesn’t seem like an overhaul or a reformulation to me; more just a great addition. You should still be able to build the input files piece by piece if you wish, but allowing and introducing users to actions sounds superb. 

You guys go crazy!

On Nov 19, 2020, at 5:22 PM, Steven Shannon <scsh...@ncsu.edu> wrote:

I think anything to simplify the interface without taking away any flexibility would be great.  I agree that starting up can be a steep learning curve.

To view this discussion on the web visit https://groups.google.com/d/msgid/zapdos-users/DCBC65BA-4179-41DA-9255-318D55B3AD53%40ncsu.edu.

[Casey Icenhour]

I like all of this. Yes, it can be important to understand the underlying PDEs (especially if your simulation is doing something you don't expect), but as an app matures, I also think it's best to start considering "packaging" like this. As Alex said, we still have the option of building things piece by piece.

As far as user guides and examples - I want to make a point of improving the website over the next year and expanding the documentation available. Some improvements to MooseDocs that were used to improve the main MOOSE tutorials (like improved features for rendering and organizing, "Next" and "Previous" markers for sequential steps on different pages, etc), that I'd like to start using in our current implementation. I wanted to start with Corey's user guide and work from there. As Steve works toward another plasma workshop next summer, the website could become an excellent place to host more resources/tutorials/workshops for user reference (and new user acquisition as they stumble across it online).

Shane, could you make an issue on the GitHub containing your suggestions? I want to be able to have all of this detail on that platform as well, especially as we reference it in our future PRs.

To view this discussion on the web visit https://groups.google.com/d/msgid/zapdos-users/E40143EC-2B52-4E5C-8851-8FE398C36874%40gmail.com.

[Casey Icenhour]

One more thing related to Shane's comment on needing to look into the source code to determine parameters - I have always viewed the MOOSE website as a supplement to the source code. Not only do I get the parameters available to me as I create an input file, but also (in most cases) a description of what these objects do. In Zapdos, our core documentation has been sorely lacking, making the synergy between the two pretty poor. I'd like to propose adding documentation pages for each new object that is added to the app. We also need to go back and add these in more detail for the objects that are missing any sort of description beyond the basics.

[Shane Keniley]

Great, I'm glad everyone is on board with this! I'll work on putting this into an issue now. Should be up soon. 

Casey, you're right about the website -- for general MOOSE classes that works really well and it would be great to have that same level of detail available for Zapdos and Crane.  Adding documentation for each object would be good. While we do that, I think it would also be a good time to make sure parameters are consistent between classes -- for example, sometimes electrons are added with the input parameter "electron", and sometimes it's "em". Ions also vary between "ions", "charged_species", and "ip".