Replacement for SmoothMeshLines
Moderator: thorsten
Replacement for SmoothMeshLines
Hello,
as I mentionend in my other thread, I run into trouble using the SmoothmeshLines: I got some errors that the generated mesh increases / decreases to fast. I thought a lot about the mesh generating problem and found the following solution:
Mesh creation could be done via a simple try and error approach: The next mesh point could be between lastDistance*ratio and lastDistance/ratio away from the last mesh point. If a fixed mesh point exist in this distance, this point is used. If there is a fixed mesh point below this distance, the last (determined) mesh point is wrong, go back and try with a mesh point a few mm below. (If that is not possible because the distance to the mesh point behind the last point is to low, also update this mesh point). This algorithm could be easily programmed using a recursive function.
Note: For the first version, I created the Matlab code shown in the openEMS_genreateMesh.m file. Unfortunatly the code does not work for me (Matlab version R2011b): Matlab seems to have a big problem with the for loop inside a recursive function call stack. So I created a MEX file which is called from the openEMS_generateMesh.m file and does the job.
I tested the function with a few examples an I seems that the algorithm works very well. The checkMesh function returns no increase / decrease errors and seems to bee more smooth than the result of SmoothMeshLines. (I got a "Mesh resolution is to low" error which was caused by a error in the checkMesh function. Now, I get only "Mesh resolution is larger than max_res" which seems to be a numeric problem.)
Problem may ocour if the ratio is to low. At a value of 1.2, the calculation takes a very long time (I does not wait for the end), so I added this boundary to the code.
I'm sure the code is not perfect, but I may be helpful.
Best regards,
Florian
as I mentionend in my other thread, I run into trouble using the SmoothmeshLines: I got some errors that the generated mesh increases / decreases to fast. I thought a lot about the mesh generating problem and found the following solution:
Mesh creation could be done via a simple try and error approach: The next mesh point could be between lastDistance*ratio and lastDistance/ratio away from the last mesh point. If a fixed mesh point exist in this distance, this point is used. If there is a fixed mesh point below this distance, the last (determined) mesh point is wrong, go back and try with a mesh point a few mm below. (If that is not possible because the distance to the mesh point behind the last point is to low, also update this mesh point). This algorithm could be easily programmed using a recursive function.
Note: For the first version, I created the Matlab code shown in the openEMS_genreateMesh.m file. Unfortunatly the code does not work for me (Matlab version R2011b): Matlab seems to have a big problem with the for loop inside a recursive function call stack. So I created a MEX file which is called from the openEMS_generateMesh.m file and does the job.
I tested the function with a few examples an I seems that the algorithm works very well. The checkMesh function returns no increase / decrease errors and seems to bee more smooth than the result of SmoothMeshLines. (I got a "Mesh resolution is to low" error which was caused by a error in the checkMesh function. Now, I get only "Mesh resolution is larger than max_res" which seems to be a numeric problem.)
Problem may ocour if the ratio is to low. At a value of 1.2, the calculation takes a very long time (I does not wait for the end), so I added this boundary to the code.
I'm sure the code is not perfect, but I may be helpful.
Best regards,
Florian
 Attachments

 checkCreateMEXfile.m
 Help script to handle MEX files
 (2.59 KiB) Downloaded 509 times

 openEMS_generateMeshMEX.cpp
 (4.76 KiB) Downloaded 485 times

 openEMS_generateMesh.m
 (5.22 KiB) Downloaded 492 times
Re: Replacement for SmoothMeshLines
Hello Florian,
thanks for sharing your code. Mesh generation is one of the weaker points in openEMS.
Did you take a look at SmoothMeshLines2.m which is distributed with openEMS? It also uses a recursive function, if I remember correctly.
Sebastian
thanks for sharing your code. Mesh generation is one of the weaker points in openEMS.
Did you take a look at SmoothMeshLines2.m which is distributed with openEMS? It also uses a recursive function, if I remember correctly.
Sebastian
Re: Replacement for SmoothMeshLines
Hi,
thanks for working on the mesh generation front
We have tried a lot on this front and not yet found a solution that always works. To be honest, I doubt that your solution will always work, but I hope it does
I will be able to give it a try next week. Tomorrow I'm going to a conference until Sunday.
Do I understand correctly that the "mfile" and "mexfile" was trying to achieve the same?
Because I would always favor a solution not including a mexfile. It is just easier to maintain.
Especially if Octave and Matlab should be able to run it.
What the ultimate goal would be is to have something like
CSX = GenerateMesh(CSX, SimBox, unit, max_res);
or something similar.
This function should contain a function like
 mesh = DetectEdges(CSX,mesh); to detect e.g. any edge of a box and add a line for that.
 a good smoothing function
 at last the existing "DefineRectGrid" function.
best regards
Thorsten
thanks for working on the mesh generation front
We have tried a lot on this front and not yet found a solution that always works. To be honest, I doubt that your solution will always work, but I hope it does
I will be able to give it a try next week. Tomorrow I'm going to a conference until Sunday.
Do I understand correctly that the "mfile" and "mexfile" was trying to achieve the same?
Because I would always favor a solution not including a mexfile. It is just easier to maintain.
Especially if Octave and Matlab should be able to run it.
What the ultimate goal would be is to have something like
CSX = GenerateMesh(CSX, SimBox, unit, max_res);
or something similar.
This function should contain a function like
 mesh = DetectEdges(CSX,mesh); to detect e.g. any edge of a box and add a line for that.
 a good smoothing function
 at last the existing "DefineRectGrid" function.
best regards
Thorsten
Re: Replacement for SmoothMeshLines
Hello,
@Sebastian: I recognized that this file exists. I also tried to use this function, but the checkMesh function also reports some errors. I does not spend any time to understand the algorithm of checkMesh2 (The algorithm comments are very poor )
Here my test code:
Both SmoothMeshLines functions generate meshs which increases/decreases to fast.
@Thorsten:
I'm working on different Computers using different operating systems which are synchronized via subversion. To ensure that I always use the last up to date mex file, I wrote the checkCreateMEXfile which must be executed before the mex function call is performed. That is the reason, why the openEMS_generateMesh exists: It calls the checkCreateMEXfile and then executes the MEX file. As the .m file already exists, I do some checkings and sorting of the input variables there because it is easier than to do that in the mex file.
I also appended the .m file to my post, because it includes the Matlab code of my algorithm. Maybee it is helpful to understand the algorithm.
Using of mex files is not a perfect solution, I know. Currently it is only a proof of concept. If the algorithm realy work, I is possible to rewrite the function in matlab code without recursive function calls. But at the moment, I does not have time to do that. Also, in my opinion the understanding of the algorithm is easier by using recursive function calls.
Best regards,
Florian
@Sebastian: I recognized that this file exists. I also tried to use this function, but the checkMesh function also reports some errors. I does not spend any time to understand the algorithm of checkMesh2 (The algorithm comments are very poor )
Here my test code:
Code: Select all
fixedLines = [0, 120, 121, 129.5, 133.5, 207.5, 212.5, 213.5, 214.5, 219.5, 293.5, 297.5, 306, 307, 480];
max_res = 4.9965;
ratio = 1.4;
disp('SmoothMeshLines: ');
mesh1 = SmoothMeshLines(fixedLines, max_res, ratio);
disp('SmoothMeshLInes2: ');
mesh2 = SmoothMeshLines2(fixedLines, max_res, ratio);
disp('My solution: ');
mesh3 = openEMS_generateMesh(fixedLines, max_res, ratio);
@Thorsten:
I'm working on different Computers using different operating systems which are synchronized via subversion. To ensure that I always use the last up to date mex file, I wrote the checkCreateMEXfile which must be executed before the mex function call is performed. That is the reason, why the openEMS_generateMesh exists: It calls the checkCreateMEXfile and then executes the MEX file. As the .m file already exists, I do some checkings and sorting of the input variables there because it is easier than to do that in the mex file.
I also appended the .m file to my post, because it includes the Matlab code of my algorithm. Maybee it is helpful to understand the algorithm.
Using of mex files is not a perfect solution, I know. Currently it is only a proof of concept. If the algorithm realy work, I is possible to rewrite the function in matlab code without recursive function calls. But at the moment, I does not have time to do that. Also, in my opinion the understanding of the algorithm is easier by using recursive function calls.
Best regards,
Florian
Re: Replacement for SmoothMeshLines
Hi,
it is not about the recursive part. I just would prefer plain Matlab code as it is easier to maintain.
Furthermore, Matlab doesn't have a problem with a recursive approach as well. Maybe your initial Matlab code just did an infinite recursive loop?
About your testcase: It will always be possible to find a situation in which algorithm A and B will fail and C be the best. The difficult part is that they always work good.
We really need to collect such difficult scenarios as a benchmark and testsuite.
regards
Thorsten
it is not about the recursive part. I just would prefer plain Matlab code as it is easier to maintain.
Furthermore, Matlab doesn't have a problem with a recursive approach as well. Maybe your initial Matlab code just did an infinite recursive loop?
About your testcase: It will always be possible to find a situation in which algorithm A and B will fail and C be the best. The difficult part is that they always work good.
We really need to collect such difficult scenarios as a benchmark and testsuite.
regards
Thorsten
Re: Replacement for SmoothMeshLines
Hi Thorsten,
I found the error in my Matlab code. I wrote instead of . Now the attached Matlab file works as expected.
At this time, I knew the disadvantage of my algorithm: It takes a longer time to complete, especially if the ratio value is choosen to small. Using the MEX files this could be neglected because execution of MEX files is much faster than Matlab code...
Best regards,
Florian
I found the error in my Matlab code. I wrote
Code: Select all
for i=1:size(..)
Code: Select all
for i=1:length(..)
At this time, I knew the disadvantage of my algorithm: It takes a longer time to complete, especially if the ratio value is choosen to small. Using the MEX files this could be neglected because execution of MEX files is much faster than Matlab code...
Best regards,
Florian
 Attachments

 openEMS_generateMesh.m
 (4.65 KiB) Downloaded 492 times
Re: Replacement for SmoothMeshLines
Hi,
using your test case I found the bug in SmoothMesh2.m. We really should add it to our testsuite.
Are we allowed to deliver your code with openEMS under GPLv3?
Sebastian
using your test case I found the bug in SmoothMesh2.m. We really should add it to our testsuite.
Are we allowed to deliver your code with openEMS under GPLv3?
Sebastian
Re: Replacement for SmoothMeshLines
Hi,
of course you can use my code. I'm very glad that you provide openEMS with a free license and hope that I can help to improve the toolkit with this thread.
Best regards,
Florian
of course you can use my code. I'm very glad that you provide openEMS with a free license and hope that I can help to improve the toolkit with this thread.
Best regards,
Florian
Re: Replacement for SmoothMeshLines
Florian.
I like the idea of generating a mesh recursively.Good.
Could you try to run the accompanying mfile "genmesh.m" ?
The mfile works OK with SmoothMeshLines.
If I use the mex version of openEMS_generateMesh, I get one error: an empty result for mesh_z.
If I use the matlab version, I get another: "Undefined function or variable 'resultMeshPoints'" for mesh_a.
koen
I like the idea of generating a mesh recursively.Good.
Could you try to run the accompanying mfile "genmesh.m" ?
The mfile works OK with SmoothMeshLines.
If I use the mex version of openEMS_generateMesh, I get one error: an empty result for mesh_z.
If I use the matlab version, I get another: "Undefined function or variable 'resultMeshPoints'" for mesh_a.
koen
Re: Replacement for SmoothMeshLines
Hi
I used your code and I found the error in the openEMS_generateMesh (Matlab version): The width of the first mesh is determined via a try and error approach: I start with the maximum possible mesh width (max_width) and try to determine the rest of the mesh. If no resolution could be found, I use a little bit smaller mesh width and try again to determine the full mesh. In the first version of the script, the width of the first mesh is determined between max_res and min_distance where min_distance is the lowest distance between two fixed mesh points. That works for my scenarios very well, but does not work if min_distance is greater than max_res.
Now I added an if statement to catch this: If min_distance is greater than max_res, the width of the first mesh point is determined by trying between max_res and max_res/10.
I'm not very happy about the determination of the first mesh point. Maybee we should also include this point into the recursive part of the algorithm....
Anyway, your scripts are running, now. Nice simulation, maybee you can send me a few informations about your underlying problem and your simulation results?
Best regards,
Florian
I used your code and I found the error in the openEMS_generateMesh (Matlab version): The width of the first mesh is determined via a try and error approach: I start with the maximum possible mesh width (max_width) and try to determine the rest of the mesh. If no resolution could be found, I use a little bit smaller mesh width and try again to determine the full mesh. In the first version of the script, the width of the first mesh is determined between max_res and min_distance where min_distance is the lowest distance between two fixed mesh points. That works for my scenarios very well, but does not work if min_distance is greater than max_res.
Now I added an if statement to catch this: If min_distance is greater than max_res, the width of the first mesh point is determined by trying between max_res and max_res/10.
I'm not very happy about the determination of the first mesh point. Maybee we should also include this point into the recursive part of the algorithm....
Anyway, your scripts are running, now. Nice simulation, maybee you can send me a few informations about your underlying problem and your simulation results?
Best regards,
Florian
 Attachments

 openEMS_generateMesh.m
 (4.92 KiB) Downloaded 508 times