Add new component for "Reactor" and the associated Event.REACT

[dcambie]

The use of this component is to represent reaction mixtures in an LSC-PM[1]
device where the absorbed photons are used to drive a photochemical reaction.

This is essentially identical to Absorber but associated with a different event
to easily distinguish the different photon fates at the simulation end.

[1] See https://pure.tue.nl/ws/files/125461363/20190510_CO_Cambie_highres.pdf for details

[danieljfarrell]

This looks simple enough and pull requests with tests are bound to get merged!

Although I do hate introducing types. It seem that the problem this is solving is one of annotating an interaction so it can be post processed. At the moment, pvtrace does not make it easy to annotate interactions in the volume nor on surfaces (see Facet proposal for how we plan to improve surface data mining).

Like you say, events they are tied to the component type: an absorber generates ABSORB event, a luminophore generated ABSORB and EMIT events. So it's certainly logically for a reactor to generate REACT events.

I just can't help thinking that if pvtrace had a way of annotating volume events then this would not be required. Let me know what you think?

I'll probably merge this when I'm making the next release over the next week.

[dcambie]

Hi Daniel!

You are of course 100% right, in pvtrace1 I'd check the parent object at the last step to determine if the photon had been absorbed within the reaction channels, but for pvtrace 2 that is no more possible and cleanest way I found was to add a component.
I briefly looked into the facet proposal but it looks me like that would covers interfacial phenomena while photon absorption by a photocatalyst is, indeed, absorption (and therefore requires ray tracing to determine the path length and probability of abs). It could be that I am missing something about the facet thing though ;)

[danieljfarrell]

Glad to hear you are moving your simulations to version 2, I remember you did a lot of customisation on version 1. Has version 2 been easier to use so far, apart from the need to introduce the reactor component?

Yes, facets would only help for counting rays entering or exiting surfaces. For this problem you need to know an "ID" for the container object.

Well I like this sort of problem because it shows there is plenty more work to be done to make it easier to use!

Maybe returning to the idea of saving ray history in a database, with loads of metadata is the way to go; the way pvtrace 1 worked.

[dcambie]

Yes, I haven't been using it a lot, but so far but it has been great.
There are a couple of calculations I have to do for a last paper leftover from my PhD and I think I'll just release the repo with my code and include pvtrace as external dependency.

Optionally saving ray history in a DB would probably be a nice addition. In pvtrace1 the sqlite in memory DB it was rather fast and to circumvent the mem usage on large simulation I had a terrible hack that would dump to disk the DB every 10k rays or so. Clearly, I do not think that was the best approach :)
Maybe history in the tracer could collate all the metadata info that are desired per each traced photon and map them to DB (e.g. w/ sqlalchemy)?