Extending ImplicitCAD for electromagnetic simulation purposes

[firegurafiku]

Hi all. I've looked through the project and it seemed quite promising for me (despite not being updated for a while). I work on an FDTD solver and like a lot the idea of 3D scene representation as a text, thus avoiding writing another buggy CAD GUI.

For my solver to work I must specify not only the geometry of the problem (it may be an antenna array emitting the signal, for example), but also a lot of meta information, like the following:

• material properties for each object on the scene (permittivity, permeability, conductivity and so on);
• invisible wave ports, lumped signal sources and field probes;
• invisible markers for regions selected for the TF/SF procedure or NF/FF transform;
• invisible nodes to align computational grid to them;
• and possible many things like these.

Additionally, I want to be able to run many simulation runs on the same scene with different parameter values. Moreover, some parameters may come from the outside world as grid functions, not known in their analytical form. For example, I may want to specify an antenna profile as a list of points with spline interpolation between them, to get smooth line on rendering. Then do simulation, analyse results, adjust original point locations, and repeat simulation to get a better result.

Long story short, could things like these be idiomatically implemented on top of ImplicitCAD? Or I should invent another wheel for myself?

[firegurafiku]

@colah @bergey @mmachenry

Sorry for bothering you, but I would really like to hear your opinion.

[luizberti]

If you're willing to write the whole thing yourself from scratch, why not just extend ImplicitCAD yourself and merge the more generic features into ImplicitCAD (so that the project just doesn't go off scope. Just have the more specific parts implemented into your application directly so ImplicitCAD stays general purpose enough for other people to keep using it)?

This project has been slow moving for a while since the original creator went into research. I wouldn't count on anyone implementing all those things for you. But the community would certainly appreciate if you took the effort to improve the project, given the historical lack of active development.

[firegurafiku]

@luizfb Thank you for responding. Let me clarify, I don't want anybody write the stuff I want instead of me. What I'm asking is "Is it possible to do this in a natural way, fitting the ImplicitCAD architecture?". I'm not very familiar with ImplicitCAD, and I'm nor a Haskell guru, I just want to ensure that it's doable before I spend a lot of time on research. And of course the core project should stay general-purpose, with no electromagnetic extensions.

[bergey]

Sure, this seems doable. I haven't written any FDM code myself, but it seems to me the implicit representation of geometry might be quite a nice match. I imagine defining geometry via implicitCAD, EM parameters through your library (with a shared language of vectors / points), and then when it's time to extract the grid, it's very direct to check whether any given grid point in 3D is part of one of your models. Less convenient if you need your grid to have more points on the surface of objects, of course.

[firegurafiku]

@bergey

I imagine defining geometry via implicitCAD, EM parameters through your library

Currently I see these parameters as OpenSCAD language extension. Something like the following example

material(epsilon=2.6) {
    sphere(10);
}

or, better

material(epsilon(x, y, z)=f) { ... }
material(epsilon(r, theta, phi)=g) { ... }

where f and g may be defined right in ESCAD syntax or in Haskell and material directive have a full load of optional parameters: epsilon, mu, sigmaE, and sigmaH as functions of spatial coordinates. Additionally, it may worth having support for anisotropic material as epsilon or mu tensors.

I also see other EM-specific things as special commands, like tfsf_region, waveport, field_probe, and so on. Is it possible to put them in a kind of namespace (in OpenSCAD syntax, not Haskell) to avoid name clashes?

Sounds doable?

@luizfb

But the community would certainly appreciate if you took the effort to improve the project, given the historical lack of active development.

Unfortunately, at this point I cannot contribute a lot, as I'm not familiar with the project's internals yet. I have done single PR for now, but it doesn't seem to have fast response from maintainers.

[luizberti]

@firegurafiku It will not have a fast response from maintainers, you'd be lucky to get responses at all. If you're really interested in this project, as you seem to be by the recently opened issues and PRs I've been following, and are willing to commit a little bit of your time to this, you could try contacting @colah or @mmachenry on Twitter (which were the only people I've ever come in contact to from this project) and ask them to possibly add you as a maintainer and give you access to the repo.

I know @mmachenry has taken a recent effort to modernise the codebase and merge some PRs. You should maybe pitch him some ideas.

[firegurafiku]

@luizfb

You could try contacting @colah or @mmachenry on Twitter and ask them to possibly add you as a maintainer and give you access to the repo.

I like the idea, but I'm not that experienced in Haskell. Maybe some time in future. But thank you for your advise contacting them by Twitter, I think this may fasten the request–feedback loop.

[julialongtin]

This is a neat idea, might i recommend you start with something small, like color support in .AMF format?