Eulumdat file handiling

[Alfie58]

Currently I'm importing a Eulumdat file for a 1.8m fluorescent lamp with a 2cm circular cross section having a uniform directional output over 360 degrees. It works fine. However, rather than importing multiple such luminaire files to make a 1m wide bank of these lamps, it seems it is likely to be more efficient to redefine the Eulumdat file as a 1.8m long lamp with a rectangular cross section 2cmx100cm ie. a single wide flat lamp. Is this just a matter of inserting the appropriate dimensions in the Eulumdat file? Will LUMOS be able to handle this as a single lamp emitting uniformly in all directions. For example, I need the reflections from the wall immediately behind the large flat lamp to reflect light correctly into the room.

[Frudawski]

LUMOS uses the photometric law for the light distribution calculation, that means all light sources are treated as point light sources. To avoid errors in the calculation, LUMOS checks, if the distance to the surface in question is at least 5 times larger as the longest luminaire dimension. If not, LUMOS automatically subdivides the luminaire into a grid of sub-luminaires within the luminaire dimensions with the same luminous distribution curve but reduced luminous flux, e.g. 10 sub luminaires with a 1/10 of luminous flux.

Hence, it should be just as simple as providing the correct luminaire dimensions in the EULUMDAT file.

[Alfie58]

Yes, that works fine. I have tried it with one wide luminaire. I need 7 - one on each of the 7-sided of the room. Once I add a second I seem to have overloaded things:-

'MATLAB:badsubscript Index exceeds the number of array elements. Index must not exceed 0. Error at line: 577 in surfaces_radiosity_calculation.m:'

[Frudawski]

Both luminaires have a spectrum applied? The error message: Index must not exceed 0 implies that there is an empty array somewhere. I will try to recreate the issue in the coming days to figure out were the problem lies.

[Alfie58]

Ah sorry, I jumped to wrong conclusion - I failed to select the spectrum. Apologies. It works now - getting there......

[Alfie58]

If you have time - maybe just check over this image. I'm guessing I may need a smaller grid setting, the lighting seems a bit fragmented - when it is expected to be uniform.

Can I check that LUMOS treats the luminaires as transparent?

[Frudawski]

Yes, a finer mesh density setting would help here. The standard setting is roughly 5 patches per m², the smaller the room geometry is, the higher the density setting should be. I would try if 25 is sufficient or go for 50, but calculation time will significantly increase. Best start with one luminaire to figure out which setting suits your needs.

Luminaires should indeed be treated as transparent during room reflexion calculation.

[Alfie58]

tried mesh setting of 50 but does seem to affect the distribution of irradiance on one panel (the other two not too bad)

[Alfie58]

it looks like no amount of increase in grid size or number of reflections will smooth/change the spot-pattern seen in the illuminance image of one of the walls. However, I note that the mesh is very fine at the centre of the wall (see below). Could, perhaps, the spot pattern seen in the illuminance be an artefact of the mesh that could be removed by some sort of smoothing of the illuminance distribution? Otherwise, I can't see a way around this.

[Frudawski]

Please excuse my late reply.

LUMOS has a simple mesh "optimization" implemented that basically sends out rays from the luminaires in all directions and the intersection points with surfaces are added to the mesh. This should ensure a finer mesh near the luminaires. In your case this is not ideal, as the optimization is only performed from the luminaire centre. I will think about making that option selectable and also address long luminaires in the next version. For now, you can simply turn the code from line 260 to 315 in the meshing.m file into a comment and the mesh optimization should vanish.

Judging from your mesh, I would say you can increase the mesh density if the calculation time is still acceptable.

[Alfie58]

can I just check which LUMOS function the code line numbers 260-315 refer to?

[Alfie58]

LUMOS mesh function I'm guessing.....

[Frudawski]

Sorry again for the late reply,

yes the mesh function, which is located in a separate file named "meshing.m".

[Alfie58]

Can you check if these are the lines of code in Meshing.m (260-315) in LUMOS version 1.11 you intended to be commented out:-

Q = [px(1) py(1) pz(1)]; % surface normal (y-z plane) n = [1 0 0]; for L = 1:size(luminaires,2) %luminare emittance vectors [alpha,theta] = meshgrid(15:27.5:345,15:27.5:345); theta(:,2:4:end) = theta(:,2:4:end)+11.25; theta(:,4:4:end) = theta(:,4:4:end)+11.25;

    alpha = deg2rad(alpha);
    theta = deg2rad(theta);
    [Lx,Ly,Lz] = sph2cart(alpha(:),theta(:),ones(size(alpha(:))));
    Lxyz = (R*(P*[Lx Ly Lz]'))';
    Lx = Lxyz(:,1);
    Ly = Lxyz(:,2);
    Lz = Lxyz(:,3);
    % intersection calculation parameters
    p = dot(luminaires{L}.coordinates,n);
    vecr = dot([Lx Ly Lz],repmat(n,size(Lx,1),1),2);
    para = -p./vecr;
    S = (para.*[Lx,Ly,Lz]);
    % intersection points
    lumrayx = [lumrayx;S(:,2)+luminaires{L}.coordinates(2)];
    lumrayz = [lumrayz;S(:,3)+luminaires{L}.coordinates(3)];

%{
% debuging
if dummy
    hold on
    plot3(luminaires{L}.coordinates(1),luminaires{L}.coordinates(2),luminaires{L}.coordinates(3),'r*')
    plot3(Lx+luminaires{L}.coordinates(1),Ly+luminaires{L}.coordinates(2),Lz+luminaires{L}.coordinates(3),'r.')
end
%}

end

ind = lumrayx>min(py) & lumrayx<max(py);
lumrayx = lumrayx(ind);
lumrayz = lumrayz(ind);
ind = lumrayz>min(pz) & lumrayz<max(pz);
lumrayx = lumrayx(ind);
lumrayz = lumrayz(ind);

end

% observer ray2plane grid points orayx = []; orayz = [];

% TODO: change to user defined resolution % Tregenza table % almucantar number, number of patches, almucantar center angle, azimuth increament, solid angle? TR = [1 30 6 12 12; 2 30 18 12 12; 3 24 30 15 12; 4 24 42 15 12; 5 18 54 20 12; 6 12 66 30 12; 7 6 78 60 12; 8 1 90 0 12]; % patch numbers and angles %line 1: almucantars, line 2: azimuths, line 3: Patchnumber _____**__

This is the error message if I run without these:-

MATLAB:m_mixed_closed_and_open_function_defs Error: File: Meshing.m Line: 646 Column: 4 The function "plot_mesh_3D" was closed with an 'end', but at least one other function definition was not. To avoid confusion when using nested functions, it is illegal to use both conventions in the same file. Error at line: 89 in surfaces_radiosity_calculation.m: Error at line: 5973 in uitoggletool17_ClickedCallback.m: Error at line: 95 in gui_mainfcn.m: Error at line: 42 in spec_simulation.m: Error at line: 0 in @(hObject,eventdata)spec_simulation('uitoggletool17_ClickedCallback',hObject,eventdata,guidata(hObject)).m: Calcualtion time: 1 s

However, if I then remove the commenting, it works as normal.

[Frudawski]

Not exactly, sorry. There seems to be some mix up in my local code and the github version. The following lines should do the trick:

` % surface normal (y-z plane) n = [1 0 0]; for L = 1:size(luminaires,2) %luminare emittance vectors [alpha,theta] = meshgrid(15:27.5:345,15:27.5:345); theta(:,2:4:end) = theta(:,2:4:end)+11.25; theta(:,4:4:end) = theta(:,4:4:end)+11.25;

alpha = deg2rad(alpha);
theta = deg2rad(theta);
[Lx,Ly,Lz] = sph2cart(alpha(:),theta(:),ones(size(alpha(:))));
Lxyz = (R*(P*[Lx Ly Lz]'))';
Lx = Lxyz(:,1);
Ly = Lxyz(:,2);
Lz = Lxyz(:,3);
% intersection calculation parameters
p = dot(luminaires{L}.coordinates,n);
vecr = dot([Lx Ly Lz],repmat(n,size(Lx,1),1),2);
para = -p./vecr;
S = (para.*[Lx,Ly,Lz]);
% intersection points
lumrayx = [lumrayx;S(:,2)+luminaires{L}.coordinates(2)];
lumrayz = [lumrayz;S(:,3)+luminaires{L}.coordinates(3)];

%{ % debuging if dummy hold on plot3(luminaires{L}.coordinates(1),luminaires{L}.coordinates(2),luminaires{L}.coordinates(3),'r*') plot3(Lx+luminaires{L}.coordinates(1),Ly+luminaires{L}.coordinates(2),Lz+luminaires{L}.coordinates(3),'r.') end %}

end

ind = lumrayx>min(py) & lumrayx<max(py); lumrayx = lumrayx(ind); lumrayz = lumrayz(ind); ind = lumrayz>min(pz) & lumrayz<max(pz); lumrayx = lumrayx(ind); lumrayz = lumrayz(ind); end `

[Alfie58]

Yes, that's it (provided I don't comment out the final 'end'). Thanks. I'll get toward on increasing the mesh density a bit - but the results already look better.

[Alfie58]

I have two luminaires offset slightly from two walls of the room. The wall mesh (with optimisation off) appears identical. However, the luminance distributions on the wall (see image) appear very different. Bit concerned there remains a problem that I am missing. Any ideas?

[Frudawski]

It seems to me, that one of the luminaires is not considered in the simulation at all. Would you provide me with your example file? I would be delighted to have a look into it.

[Alfie58]

The Eulumdat isn’t mine to publish on GitHub sadly. Otherwise I’d be happy to post it.

On 22 Nov 2023, at 05:46, Frederic Rudawski @.***> wrote:

It seems to me, that one of the luminaires is not considered in the simulation at all. Would you provide me with your example file? I would be delighted to have a look into it.

— Reply to this email directly, view it on GitHub https://github.com/Frudawski/LUMOS/issues/10#issuecomment-1822151416, or unsubscribe https://github.com/notifications/unsubscribe-auth/BAJ6WOMDIBUOWKSTI2ZX4ITYFWGUFAVCNFSM6AAAAAA6NRFM5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGE2TCNBRGY. You are receiving this because you authored the thread.

[Frudawski]

I have updated the repository, the issue should be resolved now.

There are some more changes in LUMOS: 1) Luminaire mesh optimization now works also with long and area luminaires. 2) Luminaire mesh optimization is now selectable: the "opt" checkbox in the simulation table. 3) The luminaire rotation bug should be fixed now, you will have to delete and add your second luminaire again to resolve an erroneous rotation data issue within it. 4) Luminaire renaming now works as intended. 5) Luminaires should now be visible in the results. 6) Luminaire luminance in fisheye rendering fixed, when adding an "observer" in the metrics menu. 7) Luminaire geometry data for light distribution calculation now uses the luminous width and length data from the EULUMDAT file.

Mind that for now the luminaire illustration in the results will show the total luminaire length and width despite point 7. This is something I have to "fix" in a later release.