ToFuProject
Numerical Etendue calculation using old variable names
Turning on numerical etendue calculation when using the function _class8_etendue_los.compute_etendue_los throws the attached error. Seems like some variables the embedded function wants were renamed at some point.
Here is some minimum working code using the collection object from the tofu_sparc workflow: `from tofu.data import _class8_etendue_los as _etendue_los
dcompute, store = _etendue_los.compute_etendue_los( coll=diag, key='XRSHRKr', # etendue analytical=True, numerical=True, res=None, check=False, margin_par=None, margin_perp=None, # equivalent aperture add_points=None, convex=None, # bool verb=None, plot=True, store=False, )`
ok I get it,
easy short-term fix: set numerical=False
And I'll fix that option in the next version (you're right, I forgot to update the code for numerical=True).
numerical = True is mostly used for convergence studies of the numerical estimation of the etendue (actually computing the 4d integral: i.e.: integrating the solid angle subtended by the detector-aperture system from the plasma on a plane perpendicular to the LOS).
But most of the time the analytical formulations are good enough (tofu uses 3 analytical (or semi-analytical) approximations, from coarse to fine, the last one is almost always very accurate)
Yeah, my buddy was asking about possibly having detectors at weird angles with respect to the aperture. I briefly scanned the solid angle calculation for the 2nd order analytic approximation and it seemed to handle the polygon outlines arbitrarily just fine, but wanted to confirm that's good advice. Any reason the approximations would break down, i.e. too compact optics, too weird angles?
Yeah, the 2nd order analytic should handle fine more or less any configuration / angle between the detector and the aperture. You can also have several apertures per detector.
It should start to break down (gradually) if the distance between the detector and the first aperture is very small (more precisely if the squared distance is small with respect to the detector surface and also to the aperture surface). That's when the numerical computation should start being more reliable (at th expense of a longer computation and requiring a sufficient resolution for discretizing the integrals).
I wanted to test that but never found the tine to try it, so I'll fix the numerical=True option in the next release and your buddy can test it in these extreme configurations if he wants to