>From my personal point of view, MEEP is mostly used for scientific research rather than engineering. Most simulations therefore deal with complicated physical interpretation of rather simple structures. The highlights of MEEP are the possibility to defive various physical phenomena and its scripting interface that enables to build complex pre- and post-processing around the actual FDTD computation.
This is also my case: Being able to easily inspect the structure in Mayavi or Paraview, I had no issues with definition of the model. In fact, the time spent "programming" the structure is negligible compared to that one spent with debugging the simulation, or comparing the results against other sources and dealing with the physics around. I will be interested if one writes a CAD for MEEP, but it has to be competitive to the existing workflow I am used to. If an interface to some CAD is to be written, the CAD should in optimal case: 1) be fully parametric, to allow scanning through parameters or their automated optimization, 2) enable to define all other MEEP structures, such as field sources and monitors, perfectly matched layers, boundary conditions etc., 3) be also aware of the discretized grid of FDTD, so that the structure can be defined with single-voxel accuracy. If these features would be missing in the CAD, my workflow would be arguably more efficient if I stayed with Python scripts and Paraview. In fact, I find the programming interface surprisingly friendly. Regards, Filip 2015-04-21 16:15 GMT+02:00, John Ball <ballman2...@gmail.com>: > I can't speak to the needs or limitations of the lib-ctl interface > w/epsilon-input-file; However, having spent a lot of time now perfecting my > model structure in the C++ meep format I have a few opinions there: > > I've been boot-strapping myself a sort of custom c++ based input_epsilon > function that reads the contents of an hdf5 file and uses the location > indices of the structure volume to initialize the correct epsilon value (I > do this because the process of making the epsilon grid itself takes > forever, so I've found it to be far more useful to separately create it and > store it for later use). If a FreeCAD module/plugin (sorry, I don't know > the program) could be used to intelligently create & store such an hdf5 > file (or whatever file format might be the most practical), I can see that > being useful--especially if the module could take a vrml mesh or something > similar and convert it into the pixel-based format that is the most easily > used by an eps() function when using c++ meep. Extra bonus points if the > FreeCAD module can compress the structure somehow and you can supply a c++ > function that can accurately decompress the structure for initialization by > eps(). My eps hdf5 files can get huge, but I don't have the time/motivation > to figure out any compression myself. > > After that, my expertise drops considerably; however, if you could use a > GUI to design the sources, detectors, etc, even if all it did was build a > C++ function with the meep libraries that could be then compiled and run > separately, I imagine that would be useful for many people, especially new > users. > > All of this could probably be done to build lib-ctl scripts instead (or > hell, even in addition). I prefer the C++ method because it allows me to > use functions from other libraries as well. > > I like your idea, or at least the version of it that I see in my mind. I > hope you take it somewhere! > > On Tue, Apr 21, 2015 at 2:54 AM, Alex <to.sa...@gmail.com> wrote: > >> Hi Robert, >> There is no need to bring in MEEP's code to FreeCAD. MEEP has build-in >> function "epsilon-input-file". If FreeCAD will have capability to >> export structure into HDF5 file, MEEP will just import that files. >> It is accepted to call GPL programs from not-GPL. >> >> Best regards, Alex Friman >> LPI RAS >> >> 2015-04-21 9:37 GMT+03:00 Robert Rehammar <rob...@rehammar.se>: >> > Dear Meep users, >> > >> > I have been using Meep in the past and finds the tool nice and >> > powerful. >> If >> > comparing to commercial CEM tools, I would say Meeps front-most >> > weakness >> is >> > the lack of a GUI to interface the tool and create the model in. There >> is a >> > FOSS CAD tool with good traction known as FreeCAD (freecadweb.org) >> which is >> > very nice and I think Meep would fit excellent as a module to FreeCAD. >> How >> > would the Meep community feel about that? FreeCAD is written in C++ and >> > Python and has support for things like storing material properties in >> > modelled objects, parametric modelling and large import/export of CAD >> file >> > formats. >> > >> > Looking at this, I found one obstacle and that is that FreeCAD is LGPL >> and >> > Meep is GPL. Seems like the FreeCAD-devs are very reluctant to bringing >> in >> > GPL code into FreeCAD. Anyone has any idea on how that could be solved? >> One >> > way I guess is to only use FreeCAD to generate ctl-files for Meep to >> > execute, and not link against Meep. This might be a solution, but maybe >> > limiting in the long run? >> > >> > Looking forward to hearing any thoughts on this for a possible future >> > project. >> > >> > Kind regards, >> > >> > Robert Rehammar, >> > Alekärr 105 >> > 442 91 >> > Romelanda >> > >> > phone: +46-738-32 88 34 or +46-766 45 61 97 >> > e-mail: rob...@rehammar.se >> > web: www.rehammar.se >> > >> > >> > _______________________________________________ >> > meep-discuss mailing list >> > meep-discuss@ab-initio.mit.edu >> > http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss >> >> _______________________________________________ >> meep-discuss mailing list >> meep-discuss@ab-initio.mit.edu >> http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss > _______________________________________________ meep-discuss mailing list meep-discuss@ab-initio.mit.edu http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/meep-discuss
