Rfluxmtx stdin

[ladybug-tools]

Rfluxmtx stdin

[sariths]

While staying on the issue, how are we creating points files (rays). I know that you have an implementation inside GH/HB which does it. Will be relying on the gui of GH/Dynamo to generate pts files ?

[sariths]

Final Receiver for RfluxMtx.

@mostaphaRoudsari This is somewhat of a thinking out loud type of thing...but anyways, here goes:

For most of the simulations that we use, the final receiver will always be the sky. The rfluxmtx type definition for this is :

#@rfluxmtx h=u u=Y
void glow ground_glow
0
0
4 1 1 1 0

ground_glow source ground
0
0
4 0 0 -1 180

#@rfluxmtx h=r1 u=Y
void glow sky_glow
0
0
4 1 1 1 0

sky_glow source sky
0
0
4 0 0 1 180

The part about ground in the first half of the string above is unlikely to change. The second part, ie. the sky portion will change based on the kind of sky that we choose. Andy's example uses Tregenza sky and there for h=r1, however we could use further subdivisions and change the sky conifgurations.
To sum up, I think we could probably implement a @staticmethod type thing for generating skies.. the function could be something like

def genRfluxSky(skyType =1 ):

        ...............

         return skyString

I am still testing out a few things on my side. I will keep this discussion going ....

To add to this ...

Linking (annual or point-in-time) Sky Radiation Data to First Phase

I think we might not have much leeway in setting the h= value for the sky as well as this would most likely get decided by the -m property of Gendaymtx and Genskyvec. From the sky definition above, the ground patch is created in Rfluxmtx by #@rfluxmtx h=u u=Y which links to the the 0 in (0 + 145) or (0 +2305) sky patches. #@rfluxmtx h=r1 u=Y will decide whether the patches are 145 or 2305.