Add blog post examples to documentation/tutorials

[sebastiangrimberg]

Add meshes, configuration files for the applications from https://aws.amazon.com/blogs/quantum-computing/aws-releases-open-source-software-palace-for-cloud-based-electromagnetics-simulations-of-quantum-computing-hardware/ to the examples section of the documentations, with associated writeups.

This adds some larger scale examples to the included tutorials for benchmarking, along with quantum hardware-specific walkthroughs for users.

[hughcars]

A few questions:

• For the metamaterial case, do we want to include meshes for all repetitions?
• Do we want to include the plot generating functions/scripts and/or the julia driver/submission functions?
• The meshes are generated in mphbin, should we be using something like git lfs to store these? It looks like it is supported

[sebastiangrimberg]

1. (and 3.) The thing making me avoid the metamaterial case is that the meshes are quite large, and there are many. I think it is probably sufficient to do only the transmon case, and can decide if the 17MB mesh file is big enough to need LFS or not. We could always create a separate repo in the future if we want to distribute the metamaterial waveguide example as a self-contained example.

2. I'm inclined to say no for this case, the goal would be to just walk through the problem setup, configuration file options, and results.

[hughcars]

1. An example repo is probably the correct solution for these bigger examples. They're not key for learning Palace, but they are kind of helpful to see the set up for a more "serious" case. Can also consider adding the comsol models that generated the meshes there too. Both the transmon and the metamaterial are parameterized to allow for changing things, (all the lengths etc. in the transmon, and the number of reps in the metamaterial), could make for a more interactive style demonstration.

2. Sounds good, so it'll be the base config file. There's 1 for the transmon, and there's one for each repetition count for the metamaterial due to the changing number of boundary surfaces.

Follow up thought: To make the example quantum specific hardware, is it worth including the calculations that give the geometry (Ej Ec etc.) or should it be written with the geometry as given? It's a case of what would make it more interesting for the quantum background I suppose.

[fieldMC]

Hi,

I am attempting to use Palace for the first time (outside of running the example scripts) by simulating 5 microstrip resonators coupled to a feed line. I was wondering if there was an update on the blog examples as I think they would be very helpful for what I am trying to do.

[sebastiangrimberg]

Hi @fieldMC, thank you for your interest! This has fallen a bit behind schedule with some other things we have been working on, but should be relatively straightforward to finalize in the coming weeks. In the meantime, if you have any specific questions for getting started with simulating your model using Palace, I would be happy to do my best to help out if you want to just follow up in this issue.

[fieldMC]

Thank you @sebastiangrimberg, I am trying to set up the simulation to run similarly to the cpw example. I used COMSOL to set up the vacuum with the silicon substrate in it and the device layout (set as a PEC) on the substrate. The error I am receiving at the moment is:

Verification failed: (info2 < 0) is false:
 --> MaterialPropertyCoefficient should only be used for exterior (single-sided) boundaries!
 ... in function: static int palace::MaterialPropertyCoefficient<Type>::GetAttribute(mfem::ElementTransformation&) [with palace::MaterialPropertyType Type = palace::MaterialPropertyType::INV_PERMEABILITY]

The only materials I defined in the config file were silicon and air. I have a feeling the error could come from incorrectly assigned Attributes either in the wave port, domains or PEC. I am not sure what else would be helpful to show you.

[sebastiangrimberg]

@fieldMC This error is likely occurring because you have defined wave port boundaries internal to the computational domain. Unlike lumped port boundaries, wave ports must be defined on the outer boundary of the computational domain and be "one-sided" in the sense that mesh elements only exist on one side of the boundary. For an explanation of this, see for example the descriptions of lumped and wave ports in HFSS here. I realize now that our documentation around this for Palace is insufficient so will file an issue to update it and make it more clear for users.

[fieldMC]

In reflection this makes a lot of sense, it seems to be working now. Thank you for the help!

[ferrispnugraha]

Hi, I also second this suggestion, particularly for the EPR eigenmode analysis. It is said that Palace will automatically perform EPR simulation and output the result in port-EPR.csv once we defined the config["Boundaries"]["LumpedPort"]. I wonder if we can have the .msh and .json configuration example in addition to the available documentation.

[sebastiangrimberg]

Thank you for the reminder here, @ferrispnugraha. I agree it will be a useful instructive example and I should be able to get to this sometime in the coming one or two weeks.

[ferrispnugraha]

Looking forward to the examples @sebastiangrimberg ! For my case, I am performing eigenmode analysis on system with some floating PEC surfaces and also define ground boundaries in some of them, but I encountered:

MFEM abort: Configuration file should not specify both "PEC" and "Ground" boundaries! ... in function: void palace::config::PecBoundaryData::SetUp(palace::config::json&) ... in file: /tmp/fpnugraha/spack-stage/spack-stage-palace-0.11.2-al5y6dpgguqcltpv5y522egiw4wdtmoo/spack-src/palace/utils/configfile.cpp:525

Curious what is the case. I have tried to make sure that they do not overlap or are double-counted.

[hughcars]

@ferrispnugraha I believe your issue is that the "Ground" boundary condition is only for electrostatics problems, as noted here. Your confusion might be due to a naming issue, so I'll try to expand: a "Ground" boundary condition is specifying that the electrostatic potential (a scalar quantity) is homogeneous Dirichlet on the boundary, namely equal to zero exactly, whereas a "PEC" boundary is also a homogeneous Dirichlet boundary condition (setting a quantity to zero by setting degrees of freedom identically equal to zero), these are on the tangential component of the electric field (a vector quantity).

The eigenmode problem description is solving for the electric field E, which looking at the gauge relations can be in a simplification thought of as the gradient of the electrostatic potential. So attempting to apply a "Ground" boundary condition on an eigenmode simulation is like trying to apply an essential boundary condition on an integral of the electric field on the boundary, which is non-trivial and not handled within Palace. Does that make sense?

[ferrispnugraha]

Now it makes sense @hughcars , thank you for clarifying the concepts.

[aleaj]

1. An example repo is probably the correct solution for these bigger examples. They're not key for learning Palace, but they are kind of helpful to see the set up for a more "serious" case. Can also consider adding the comsol models that generated the meshes there too. Both the transmon and the metamaterial are parameterized to allow for changing things, (all the lengths etc. in the transmon, and the number of reps in the metamaterial), could make for a more interactive style demonstration.
2. Sounds good, so it'll be the base config file. There's 1 for the transmon, and there's one for each repetition count for the metamaterial due to the changing number of boundary surfaces.

Follow up thought: To make the example quantum specific hardware, is it worth including the calculations that give the geometry (Ej Ec etc.) or should it be written with the geometry as given? It's a case of what would make it more interesting for the quantum background I suppose.

Hi I am also interested in using Palace for qubit simulation and I wonder if this could still be possible. I would like to import models from Comsol and run them but have troubles creating the config file and exporting the Comsol mesh. Thank you.