Luminaire about lumos

[Frudawski]

LUMOS uses the geometry data that is provided in the .ldt (EULUMDAT) files. So, if you switch to another luminous intensity distribution (EULUMDAT file) the geometry of the luminaire should change accordingly. You can edit the .ldt (EULUMDAT) file yourself with a text editor, lines 13-15 are relevant for the geometry.

See: https://docs.agi32.com/PhotometricToolbox/Content/Open_Tool/eulumdat_file_format.htm

[Frudawski]

You can create complex objects by combining simple objects, here are some hints how to handle objects:

1. Go to the object tab, a list of all objects will appear. In the table one can adjust the relative coordinates of each object inside the room geometry and also rotate them.

2. By selecting any object from the list one can edit the object in the table. Using a right click in the table, one can add or remove additional points.

3. In the material tab one can assign the desired materials.

4. Back in the object tab, there is a „group tool“ in the toolbar, which allows to group or ungroup any objects.

5. Also in the object tab, there is an „export tool“ in the toolbar which allows to save any (also grouped) object.

6. In any other LUMOS project one can now import the saved object with the „import tool“ in the toolbar.

[Frudawski]

Sorry, your first question somewhat escaped my attention.

EULUMDAT files are measured as point light sources and are mostly treated as that. To avoid simulation errors in situations as described, one can divide the luminaire in smaller sections in the simulation, e.g. ten segments with 20 cm length, with the measured luminous intensity distribution but a tenth's of the luminous flux. Like other lighting simulation programs, LUMOS should do that automatically to some degree.

The threshold in LUMOS for dividing a luminaire into smaller sections is: distance luminaire-to-patch / luminaire's longest side < 5. If you upload an example, I could check if there is an error in the automatic luminaire subdivision. Or you divide your luminaire manually into smaller segments and adjust the luminous flux accordingly.

[Frudawski]

Thank you for the example file. I found a bug in the luminaire subdivision, which I was able to fix. If the luminaire was rotated, as in your case, the automatic subdivision was not working reliable.

Please get the new LUMOS version 1.09 from the repository, your simulation should then look something like this:

[Frudawski]

Make sure you add the luminaire's dimension to your EULUMDAT file, what seems to be the case in two of your example plots. In your example EULUMDAT file, the lines 13-15 were blank though, I had to add those manually since LUMOS gets the luminaire dimensions from the EULUMDAT file. Maybe you forgot this in your quick test?

Just in case, the link to the EULUMDAT file format explanation:
https://docs.agi32.com/PhotometricToolbox/Content/Open_Tool/eulumdat_file_format.htm

Otherwise, the lines 651+ in surfaces_radiosity_calculation.m should now look like this in version 1.09:

            % luminaire max dimension
            lumrotM = rotMatrix(luminaires{lum}.rotation);
            dim = max(diff(luminaires{lum}.geometry{1}));
            lumdim = dim(1:3)*lumrotM;
            mdim = max(dim(1:3));

But that is not the only change I had to make.

[Frudawski]

I did not try the MATLAB add-on way of installation. It should work, but it seems to me, that the version is currently one step behind in the add-on menu of MATLAB. The same is true for the File Exchange version apparently. I have to look into it.

[Alfie58]

Hi, I've figured out the EULUMDAT files needed and can load these. Thanks for your help. Can I save myself some effort by asking you if the coordinates of the object (as opposed to the luminaire), which is currently set as a cube, is imported from a file or defined in the code? I'm looking to add a complex shaped object from a file. Also, are there restrictions on the complexity of the object (maybe resulting from the radiosity calculation)? I am trying to get to grips with the code but I'm not an expert.

[Alfie58]

Thanks. I have a grouped set of four parallel fluorescent tube luminaires near the wall of a room. I've selected white walls and, just as a start, selected red brick as the spectrum of the tubes (ok - it's just because I don't have the spectrum I need just yet). It all seems to work and generates a rendered image - which looks plausible - but I get a pile of error messages that I can't seem to figure:-

'Warning: Duplicate data points have been detected and removed - corresponding values have been
averaged.

In hyperspecfisheye (line 299)
In surfaces_radiosity_calculation (line 1375)
In spec_simulation>uitoggletool17_ClickedCallback (line 5973)
In gui_mainfcn (line 95)
In spec_simulation (line 42)
In matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)spec_simulation('uitoggletool17_ClickedCallback',hObject,eventdata,guidata(hObject))
In plotGouraud (line 507)
In spec_simulation>simulation_listbox_callback (line 4586)
In spec_simulation>simulation_tab_Callback (line 6662)
In gui_mainfcn (line 95)
In spec_simulation (line 42)
In matlab.graphics.internal.figfile.FigFile/read>@(hObject,eventdata)spec_simulation('simulation_tab_Callback',hObject,eventdata,guidata(hObject))
Calcualtion time: 42 s

'

will keep working on this. But one of your useful tips might save me time.
Thanks.

[Frudawski]

The warning appears during the triangulation for the mesh generation when datapoints are doubled or are very close to each other. MATLAB automatically remove these points but will show one (or more) warning message(s) during the simulation. You can ignore this warning. I will try to remove this issue in future, but since it does not affect the functionality, it is not on the top of my todo list.

[Alfie58]

Thanks for that.
I have successfully used LUMOS to render lighting in a room with a horizontally mounted 1.8m fluorescent luminaire. The lamp shows up in position on the pre-simulation 3D plot and I get some sort of rendering that looks reasonable and that also shows the luminaire in position. The problem I am interested in is a vertically-mounted 1.8m luminaire (actually an array of these in a hexagonal room). I note the resulting simulated rendering 3D plot for a single luminaire no longer shows the luminaire. But if I place the laminar at, say 45 degrees, it shows up. Not a major issue. You may have a comment. [Appreciate that you can't be dealing will all user applications - so feel free to ignore, of course]. Maybe these plots illustrate the issue:-

[Alfie58]

what format is the imported object expected to be? .stl ? Will get there in the end! Thanks.

[Frudawski]

Concerning the disappearing luminaire: LUMOS is not good at dealing with co-planar objects, meaning that if the luminaire is exactly (or numerical close) to the wall, it might be treated as outside the room geometry. That could result in the described behavior. In general, it is better to place luminaires a few mm's or cm's inside the room geometry to be on the save side. If that does not help, fell free to upload an example with the issue and a can take a look into it.

LUMOS does only work with LUMOS created objects, no support for external created object so far. Since the calculation time does increase dramatically with geometric complexity, I don't think I will add that feature.

[Alfie58]

I have a Eulumdat file for a 2m fluorescent tube - emitting along its length in all directions. I note, however, the output appears to emanate from just a point on the length of the tube. I can test this by placing it close to a wall in a range of orientations. Any advice as to whether this an issue with my Eulumdat file or with my incorrect use of LUMOS?

[Alfie58]

Hi, wondering if you have any advice on the use of a Eulumdat file for a bare 2m fluorescent tube in LUMOS (as above). Will LUMOS treat the tube as an emitter along its length in all directions? Bit stuck on this - any advice most welcome. Thank you.

[Alfie58]

[If you have time - maybe you can check over these and see if you can spot a problem.

Tony Test Tubular Fluorescent Lamp - Mirrored.txt](https://github.com/Frudawski/LUMOS/files/12343570/Tony.Test.Tubular.Fluorescent.Lamp.-.Mirrored.txt)

[Alfie58]

thanks so much for correcting this so quickly. I had a quick go this morning but failed to get the you, obviously correct, rendered distribution. I may have messed up installation of 1.09 (although I don't think so). Perhaps if you let me know the function and a line in the code you changed in 1.09 it would help confirm if I have the latest version. Don't worry tho if time pressed. I will work on it..

[Alfie58]

That's it! All sorted. I did have the correct version 1.09 loaded. I added back the luminaire length and width, (which I'd forgotten to do). The orientation of the luminaire I had set to x=90, y=0, z = 90. Which gave me a long but horizontal light rendering on the back wall. Just by switching to z=0 sorted it and gave the correct (vertical light distribution) result.

[Frudawski]

Thank you for pointing this out. I had another look into the code and tested some different luminaire rotations and was able to recreate this issue. I had to fix two additional bugs concerning luminaire rotation and the correspondent luminaire subdivision. The new version 1.10 seems to work properly now.

[Alfie58]

Will try using the new version (1.10). Just a minor issue (apologies, I'm not all that familiar with MatLab):- if I simply uninstall LUMOS and then reload LUMOS as a MatLab add-on - will that get me the new version? Previously I got a bit messed up loading the new version and couldn't easily confirm if I had it installed without checking the coding

[Frudawski]

MATLAB did catch up with the versions, this is an automatic process, that apparently can take some time. If you want the newest version immediately after an update, the GIT approach is probably better suited. Or you download the zip archive and overwrite your local files.

[Alfie58]

Yes, I saw that MATLAB did catch up with version 1.10 eventually - and have now successfully added it on. I'll use the GIT approach in future for speed of update. Currently am trying to figure the effect of parameters on the rendered image (number of reflections, orientation of the luminaire in the z-axis etc.) Once I have a handle on these issues I will try to get some quantitative irradiance measurements at the surface of various objects (incl. a box, but also a polygon shape and shapes stacked on top of each other). I appreciate run time goes up rapidly with complexity and reflection number. Any other parameters that can be adjusted to speed things up? I also need to figure out if these shapes can be saved as I increase their complexity.

[Frudawski]

I would like to thank you for your enthusiastic approach on LUMOS, your feedback was quite valuable already.

The "number of reflections" parameter sets the number of room internal reflections after the direct lighting was calculated. Depending on your reflectance values and your use-case this parameter can be set accordingly. If you want to test other parameters, I would suggest reducing internal reflections to 1, or even turn it off by setting it to zero, in order to reduce cumputation time. The preset of 3 should be sufficient for most use-cases but if you need high accuracy you can have a glance at the formula in section 5.8 in this document to estimate the neccesarry number of reflections.

The effect of orientation of the luminaire depends on the EULUMDAT file. You have a rotationally symmetrical luminous intensity distribution, rotating around that axis should not change the results to much, if at all.

The patch density has also an influence on computation time. As long you are testing you can reduce this value, even to values <1 (as long as no glitches appear), turn off inter-reflection calculation completely by setting "number of reflections" to zero, and increase both again for the final simulation. A high patch density can resolve finer details which is also reflected in the quality of the resulting rendering. If the simulation is already slow with low settings, the final high quality simulation might need some ours or even days.

The number of total surfaces in the room is also relevant for computation time. The lower the better.

Objects can be edited, combined and saved. I fear that the object menu can be quite laggy during changes though. In the object menu a right click in the table allows to add or delete object points, which can be set to "arbitrary" positions. An object is basically divided into a bottom and top part in LUMOS, so polygonal objects might need to be assembled form sub-polygons in order to create complex figures.

The entire simulation can be duplicated in the room menu by right clicking in the room list on the left side. In the simulation menu, the simulation of each room can be turned on or off. This might be a good way to play around with different object geometries.

Good luck!