Open mkelley opened 2 months ago
If this looks good, I would proceed in a few steps:
I think this is a reasonable approach. My feeling is that there might be some redundancy in the architecture. For example, I still need to make sense of the combination of Shape, SolarSystemObjectModel, and Sphere, and maybe the organization can be simplified. But I don't have a good idea how yet. Let's move on this way and I'll keep thinking and get back if I have something.
Thanks. The concept behind the SolarSystemObjectModel (I'm open to better names) is to require the total_fluxd
method. This is a method that requires a surface and a shape. I didn't think it made sense to add total_fluxd
to any of the other classes, hence SSOM was invented.
This issue is for designing new classes around the concepts of surfaces and shapes, with the goal of being able to model surface reflectance, thermal emission, and observations of arbitrary shape models.
I may have some misunderstanding of the concepts and terminology, so comments and improvements are welcome! Also, the code below is incomplete, but there should be enough sketched out to see how it would work.
Surface
The
Surface
class accounts for all surface properties, e.g., albedo, emissivity, and how light is reflected off the surface. It has four methods. Three methods are used to describe reflectance, absorbance, and emittance. A fourth calculates the surface brightness (spectral radiance):A Lambertian surface could be implemented like so:
Surface reflectance or thermal emission classes would implement the
radiance()
method. Since we are a solar system focused project, we assume the surface is illuminated by sunlight:Surface thermal emission needs a temperature to produce a blackbody spectrum. The temperature method will be defined by sub-classes. Below we implement an instantaneous LTE class:
At this point concrete classes can be made and used:
Shape
Shape
classes would account for the scattering and observing geometry for an object. Arbitrary shapes should be possible, but I think just three classes could be provided by sbpy:Sphere
,Ellipsoid
, andTriangularMesh
.Since the problem at hand is focused on observed brightness of an object, I think we just need one method would integrate a function (e.g.,
radiance
) over the observed surface:Derived classes would take into account the object's actual geometry. For example, a
Sphere
class would run a double integral in spherical coordinates:Solar system object models
Before we can implement an asteroid thermal model, we need a mechanism that combines the concepts of surfaces and shapes. Specifically, we want something that can integrate the surface radiance over the object.
Asteroid thermal models
Now we have everything we need to implement a model like the Near-Earth Asteroid Thermal Model. The NEATM assumes a Lambertian surface illuminated by the Sun in instantaneous thermal equilibrium:
A chart that illustrates the inheritance:
Similarly, a rapid rotator model could be derived using a
RapidRotatorThermalEquilibrium
class (not shown):We also want to implement a Standard Thermal Model. Since it doesn't explicitly use the shape model, it may be simpler to implement as a stand-alone class.