Closed moellep closed 2 years ago
I've done a bit of poking around and provided below a brief summary of available open-source CAD platforms and subsequent libraries enabling Python development.
OpenCASCADE (OCC) seems to be the platform upon which most open source tools are built. It’s available with the “lesser” GPL and features cross platform support. The particular implementation of OCC that I see referenced most often is OCE, the “community edition” of OpenCASCADE. Atop this platform are various libraries which provide Python hooks for construction and visualization of CAD objects and meshes.
FreeCAD seems to be one of the most complete software applications. In addition to a functional GUI, FreeCAD includes a Python API for creating features . At first glance, it seems to be robust, but could have a steep learning curve.
PythonOCC is another open source Python package for 3D CAD. It seems to be fully featured, and is compatible with a variety of well known Python packages, including matplotlib for visualizing objects and meshes. This may be the most complete option for our purposes, but it also could be overkill.
OpenSCAD provides a full featured but wholly separate 3D CAD development from the
Thanks for the research, @ncook882.
Are you looking for CAD programs or reading/writing CAD files?
There's a numpy package that reads/writes STL: https://pypi.python.org/pypi/numpy-stl Seems like that might be easiest to integrate with Warp.
For programs, I'd recommend Sketchup or Blender. There are even some sites like clara.io and openjscad.org that will let you edit online. Might be cool to integrate with one of those.
Hi @robnagler.
What I had in mind was the ability to import/export full CAD files. Based on my understanding, STL is somewhat limited because it approximates otherwise smoothly-designed CAD surfaces. It does appear that STL is a bit easier to work with though, so perhaps we can start by including it as well.
With that in mind, I would suggest the following file formats be supported:
As far as "free" programs, I hear great things about SketchUp as well as OnShape. I had it in mind that if we were to integrate with a program, then we should use one that is open source and supports a Python interface. That's why I was originally interested in FreeCad. However, perhaps OpenJsCad is more useful for integration with the GUI due to its JavaScript API...
I thought that the purpose is to get an output that will be rendered into WARP's format (whatever that is). I kind of think of what we are doing is similar to that of a 3d printer: get the shape and characteristics.
I don't think we need/want tight integration with the program. In fact, that probably would be a mistake as some people might prefer a particular program. The structures people will design are likely to come out of sophisticated CAD programs like AutoDesk, which can "print" to STL, which (as you note) is easy to work with.
This is similar to the work going on in ROBOT, where we are likely to get regions of interest contours from a 3rd party program such as MIM. However, we might get contours from another program. All we care about is knowing those regions so we can run the beam dynamics algorithms.
Perhaps I've misunderstood the problem. Wouldn't be the first time. :)
You're correct that the goal is to enable import and export of 2D drawings from a standard CAD format. This requires two separate (let's assume reversible) steps:
What I had in mind was the construction of an "abstraction layer" between (1) and (2), wherein we represent the complete design to the best of our ability using Python or JS. It was my hope that the proper choice of platform could enable (1) without significant additional development on our part. Once we have imported the physical design, achieving (2) for simple geometries should only require some minimal legwork from within a Python environment.
My only (minor?) concern with the use of the STL library is that STL files do not reproduce CAD designs with complete fidelity. The triangulation of surfaces produces faceting which we would not care to represent in Warp. I am not well enough versed in STL to know if we can avoid this in most instances. The numpy-stl package seems straightforward enough that it's worth evaluating. If you plan to implement it for other projects, then it's a great starting point.
We do not need to support integration with CAD software. I agree with your observation that people will prefer different programs and we should aim to respect their software choice and workflow.
I'd recommend the CAD parser be written in python. The javascript side can send the file to the server and then either display the imported data or show an error message. This is similar to the ELE/LTE import with the elegant app.
The python program's output would be a list of conductorTypes (id, name, xLength, zLength, voltage?) and conductors (id, conductorTypeId, xCenter, zCenter). Keeping the result as a python dict would be fine:
{ 'conductorTypes': [ { 'id': 100, 'name': 'Shape1', 'voltage': 0, 'xLength': 0.02, # [µm] 'zLength': 0.01, }, ... ], 'conductors': [ 'id': 1000, 'conductorTypeId': 100, 'xCenter': 0.036, 'zCenter': 4.75', ], ... }
To get an idea of the format used by the sirepo app, select the "Export as Zip" option from a simulation drop-down on the Simulations page. The sirepo-data.json contained in the zip file has the data structure above.
Paul
On Wed, Aug 9, 2017 at 2:00 PM, Nathan Cook notifications@github.com wrote:
You're correct that the goal is to enable import and export of 2D drawings from a standard CAD format. This requires two separate (let's assume reversible) steps:
- Interpretation of the CAD format to some internal object(s) describing the geometry and assembly of the physical design
- The reconstruction of the design on a traditional rectangular mesh in Warp.
What I had in mind was the construction of an "abstraction layer" between (1) and (2), wherein we represent the complete design to the best of our ability using Python or JS. It was my hope that the proper choice of platform could enable (1) without significant additional development on our part. Once we have imported the physical design, achieving (2) for simple geometries should only require some minimal legwork from within a Python environment.
My only (minor?) concern with the use of the STL library is that STL files do not reproduce CAD designs with complete fidelity. The triangulation of surfaces produces faceting which we would not care to represent in Warp. I am not well enough versed in STL to know if we can avoid this in most instances. The numpy-stl package seems straightforward enough that it's worth evaluating. If you plan to implement it for other projects, then it's a great starting point.
We do not need to support integration with CAD software. I agree with your observation that people will prefer different programs and we should aim to respect their software choice and workflow.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/radiasoft/sirepo/issues/831#issuecomment-321365114, or mute the thread https://github.com/notifications/unsubscribe-auth/AGNwrom0HRULgmnYJ4Zg9lXnL_JWKURhks5sWg_SgaJpZM4OuRfP .
I was just hoping to solve the 2d problem quickly, since that's what's before us. As I understand it, Warp wants to know if an object is in or not in a grid square. If we use STEP, we will have to build some code to reconstruct the list of objects. If we use STL, I think we have a list of triangles to query, which would be easier. STEP will be more precise, of course.
I did some initial testing of the numpy-stl package. It seems pretty straightforward to read in STL meshes, get object properties (e.g. a list of vertices, faces, and "mass properties." I may play around a bit more with multiple-object meshes, but it could be a quick and dirty solution to the problem in 2D at the very least. I think it should at least be a reasonable starting point.
After a bit more tinkering, I will play around with STL import-export to verify that my scripts can properly separate files with multiple objects, and that appropriate metadata (permittivity and other features) is included as needed. I will then construct an example for Paul to adapt, with guidance on creating the requisite import/export features.
Allow importing the grid components from a CAD datafile. Add an CAD export option.