rcontrib: fatal - duplicate modifer 'M-nor'

Hi all,

I'm running a three phase method analysis and am running into some funny behaviour. I generated windows using Honeybee msh2rad, converting a Rhino mesh to a radiance geometry file via TurtlePyMesh & obj2rad.

When I generate my view matrix, it works fine for some windows, but not for others - and there's no clear difference in geometry between those that work and those that don't work. My command is:
                Rfluxmtx -ab 4 -ad 5000 -y 81 < ChEast.pts - windows_pts/window_04.rad material.rad ChEast.rad > viewpts_04.mtx

And the error I get is:
rcontrib: fatal - duplicate modifer 'M-nor'

My daylight and sky matrices work for fine for all of the windows, so I don't know what it is. Any idea what can cause this kind of behaviour? Does rfluxmtx need perfectly flat / regularly shaped objects?

Thanks,
Reinier

Here is an excerpt of my window_04.rad file:
#@rfluxmtx h=kf u=Z
void glow windowglow
0
0
4 1 1 1 0
# c:\radiance\bin\obj2rad C:\ladybug\genBSDFtest\window_03\MSH2RADFiles\window_03.obj
# OBJ file written by TurtlePyMesh

windowglow texfunc M-nor
4 dx dy dz tmesh.cal
0
10 2
    0.00014694 -0.00056977 -0.39197137
   -0.00262064 0.00269441 -1.04630966
    0.00007866 0.00016957 -0.86569177

M-nor polygon object_1.1
0
0
9
          -245.804 137.307 31.8827
          -229.021 137.314 22.0454
          -252.533 117.213 36.8545
[ it continues with more windowglow texfunc M-nor & M-nor polygon object_x.x lines]

Reinier Zeldenrust

Environmental Designer

Atelier Ten
Building Services Engineers + Environmental Design Consultants
Fire Engineers + Lighting Designers
[signature]
LONDON | GLASGOW | EDINBURGH | NEW YORK | NEW HAVEN | SAN FRANCISCO | DOHA | BANGKOK | SINGAPORE | SYDNEY
19 Perseverance Works, 38 Kingsland Road, London E2 8DD
T +44 (0)20 7749 5950
atelierten.com<http://www.atelierten.com/>
Atelier Ten is an accredited ISO 9001 and 14001 company and is a founding member of the UKGBC. This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient of this e-mail you must not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please notify the sender and then delete it from your system. Each year with Clear<http://www.clear-offset.com/>, we offset our expected CO2emissions. Company Registration Number: 255 2224. Company Registered Address: 19 Perseverance Works, 38 Kingsland Road, London, E2 8DD

Hi Reinier,

Are you being sure to group your same-material surfaces together when passing them to rfluxmtx? The program isn't smart enough to group them for you, and I suppose this requirement needs to be mentioned explicitly in the man page. That was an oversight on my part...

If your receiver surfaces are already grouped by modifier and you are getting this error, send me your files off-list and I will see if I can figure out what's going on.

Cheers,
-Greg

···

From: Reinier Zeldenrust <[email protected]>
Subject: [Radiance-general] rcontrib: fatal - duplicate modifer 'M-nor'
Date: March 12, 2015 1:38:37 PM EDT

Hi all,

I’m running a three phase method analysis and am running into some funny behaviour. I generated windows using Honeybee msh2rad, converting a Rhino mesh to a radiance geometry file via TurtlePyMesh & obj2rad.

When I generate my view matrix, it works fine for some windows, but not for others – and there’s no clear difference in geometry between those that work and those that don’t work. My command is:
                Rfluxmtx –ab 4 –ad 5000 –y 81 < ChEast.pts – windows_pts/window_04.rad material.rad ChEast.rad > viewpts_04.mtx

And the error I get is:
rcontrib: fatal - duplicate modifer 'M-nor'

My daylight and sky matrices work for fine for all of the windows, so I don’t know what it is. Any idea what can cause this kind of behaviour? Does rfluxmtx need perfectly flat / regularly shaped objects?

Thanks,
Reinier

Here is an excerpt of my window_04.rad file:
#@rfluxmtx h=kf u=Z
void glow windowglow
0
0
4 1 1 1 0
# c:\radiance\bin\obj2rad C:\ladybug\genBSDFtest\window_03\MSH2RADFiles\window_03.obj
# OBJ file written by TurtlePyMesh

windowglow texfunc M-nor
4 dx dy dz tmesh.cal
0
10 2
    0.00014694 -0.00056977 -0.39197137
   -0.00262064 0.00269441 -1.04630966
    0.00007866 0.00016957 -0.86569177

M-nor polygon object_1.1
0
0
9
          -245.804 137.307 31.8827
          -229.021 137.314 22.0454
          -252.533 117.213 36.8545
[ it continues with more windowglow texfunc M-nor & M-nor polygon object_x.x lines]

Reinier Zeldenrust
Environmental Designer

The next major release of OpenStudio (v 1.7.0, to be released at the end of March) does all of this work for you automatically. The basic workflow is in the current iteration release, in fact; OpenStudio will take an OpenStudio model and group all the window polygons by orientation, transmittance, and shading control, and all the required rfluxmtx headers are written to the window input files. This is all in OpenStudio v1.6.3. While there was an issue in the annual simulation workflow in v1.6.3, this has been fixed for v1.7.0 (and can be downloaded from the OpenStudio GitHub today).

</shameless_plug>

···

On 3/12/15, 12:22 PM, "Greg Ward" <[email protected]<mailto:[email protected]>> wrote:

Hi Reinier,

Are you being sure to group your same-material surfaces together when passing them to rfluxmtx? The program isn't smart enough to group them for you, and I suppose this requirement needs to be mentioned explicitly in the man page. That was an oversight on my part...

Cheers,
-Greg

From: Reinier Zeldenrust <[email protected]<mailto:[email protected]>>

Subject: [Radiance-general] rcontrib: fatal - duplicate modifer 'M-nor'

Date: March 12, 2015 1:38:37 PM EDT

Hi all,

I'm running a three phase method...