Working with work planes

[hamdav]

This is related to (probably exactly the same as) #135.

I want to create a work plane, create some 2D geometry in here, and then extrude it.

So first: create the model and 3d geometry and a work plane:

client = mph.start()
model = client.create()
model.create('geometries/geometry', 3)
model.create('geometries/geometry/wp1', 'WorkPlane')

When creating a work plane in comsol, a 2D geometry is automatically built (see work plane in https://doc.comsol.com/6.1/doc/com.comsol.help.comsol/COMSOL_ProgrammingReferenceManual.pdf). I can access this and for example create an ellipse with

wp = model/'geometries/geometry/wp1'
wp.java.geom().create('e1', 'Ellipse')

but I don't seem to be able to access it through wp.create('geom/e1', 'Ellipse') or anything else I've tried. Neither it nor the ellipse shows up in mph.tree(model) either.

[john-hen]

Yes, this is exactly the same as #135. And you already know the work-around: using the Java methods of the Comsol API directly.

I've closed the other issue as it wasn't very clearly phrased, so I'll leave this one open. It's ultimately a feature request. I, for one, am not planning to implement this. But if someone else wants to give it a shot, and the solution doesn't like double the lines of code in node.py, then it might go into the library. It's not a trivial change though.

[hamdav]

I might take a stab at it sometime... do you know why the problem occurs?

[john-hen]

So the Node class we have in Python is essentially "trying to be" an abstraction of "whatever type of node class" there may be on the Java side. Of which there are many. Which is why our abstraction doesn't work all of the time.

There is a reason why there are many such classes in Java. They all expose different features. Like a study node exposes different methods ("behavior") than a geometry node. However, most (not: all) nodes that have sub-features ("children" in the model tree) expose a method named feature(), in the Java API. So that covers like 95% of the cases (give or take), which allows us to traverse the model tree to a reasonable extent. But it's also missing some nodes.

Namely, all the nodes that "have children", but don't expose a method named feature(). For example, in #78 we extended that to include material property nodes. This adds more case-switching to the code base. Not just in Node.children(), but also in Node.java, Node.create(), and Node.remove(). You essentially want to add another case there.

On that note, since the case-switching already happens in four different places, it should probably be "factored out" at some point, if we're taking this further. Though it should also be said that this abstraction was never meant to reach feature parity with the Comsol API. MPh promises to cover "common scripting tasks", as stated in the introduction. So if the code becomes "too complex" (very subjective measure), I will be hesitant to include it. Just because I'll be the one stuck maintaining it. Then again, I'm obviously open to an elegant solution that makes the library more useful.