Note: This discussion is about an older version of the COMSOL Multiphysics® software. The information provided may be out of date.
Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.
Changing the relative repair tolerance seems not to be effective in any way
Posted 2013年4月30日 GMT-4 01:25 Geometry Version 4.2 3 Replies
Please login with a confirmed email address before reporting spam
I need to define a geometry that is very awkward but it's necessary, It's a sphere with a very big radius compared with the thickness of a single layer (1000 times smaller, e.g. s/r = 1e-3, where s = layer thickness and r =sphere radius).
The problem is: When I define a sphere with such dimensions, it will give me an error giving a minimum value for layer thickness, witch respects the following equation, independently of the relative repair tolerance value: s_min/r=5e-3, It was tested for relative repair tolerance between 1 and 10e-12 and for some radius values around 1 and 1e-3 in COMSOM 4.2 and just keeps giving the same value with the error.
Then I tried to define this layer by creating two spheres: one with the desired internal radius (r-s) and another one with radius equals r, and at this time, the geometry was created with no errors, and I could see that both spheres where created by hiding a boundary from the external sphere and zooming in a bit. And again, the relative repair tolerance seems to have effect in the created geometry. But I have already defined a very complicated geometry with several of those spheres with layers and it was working fine, but now I need to reduce this thickness and I don't really want to redefine the entire geometry.
By the way, as this parameter (relative repair tolerance) appears both in geometry and form union's settings, it set the same value on both every time.
I also tried to created new clean mph, just with this sphere and nothing changed, the same errors, so it's not something I defined in my model that is causing trouble.
Am I missing something here?
The problem is: When I define a sphere with such dimensions, it will give me an error giving a minimum value for layer thickness, witch respects the following equation, independently of the relative repair tolerance value: s_min/r=5e-3, It was tested for relative repair tolerance between 1 and 10e-12 and for some radius values around 1 and 1e-3 in COMSOM 4.2 and just keeps giving the same value with the error.
Then I tried to define this layer by creating two spheres: one with the desired internal radius (r-s) and another one with radius equals r, and at this time, the geometry was created with no errors, and I could see that both spheres where created by hiding a boundary from the external sphere and zooming in a bit. And again, the relative repair tolerance seems to have effect in the created geometry. But I have already defined a very complicated geometry with several of those spheres with layers and it was working fine, but now I need to reduce this thickness and I don't really want to redefine the entire geometry.
By the way, as this parameter (relative repair tolerance) appears both in geometry and form union's settings, it set the same value on both every time.
I also tried to created new clean mph, just with this sphere and nothing changed, the same errors, so it's not something I defined in my model that is causing trouble.
Am I missing something here?
3 Replies Last Post 2013年4月30日 GMT-4 15:24
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
but if you have such "thin layers, are you sure you cannot use shell or thin boundary physics instead of modelling them as "3D solids". You will anyhow have quite an issue meshing your system like that too
--
Good luck
Ivar
but if you have such "thin layers, are you sure you cannot use shell or thin boundary physics instead of modelling them as "3D solids". You will anyhow have quite an issue meshing your system like that too
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Yeah I am aware of that, both meshing and consequently obtaining the solution will require quite big computational resources, but the problem is that I need to evaluate some characteristics inside this thin layer, so unfortunately, I think a boundary condition might not be sufficient in this case.
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Well, I'm running out of alternatives here, I gave up (for while) trying to use thickness-based creation of that layer, creating this indirectly by the use of two spheres with different radius at the same central point. But to avoid doing that manually, I tried to make it through Java code, and I've got an unexpected error:
ERROR compile.java:15: code too large [com.comsol.logger
]
ERROR public static Model run() { [com.comsol.logger]
ERROR ^ [com.comsol.logger]
ERROR 1 error [com.comsol.logger]
ERROR Exception:
com.comsol.util.exceptions.FlException: Program did not exit normally
Messages:
Program did not exit normally
[com.comsol.logger]
got this code too large exception, and I'm worried that this is a Java compiler limitation (well, looks like there's more from Java for me to hate) based on the results I got when googled that.
This is the .bat file I use to compile my files, where %1 is the first argument to this batch that corresponds to the .java file path.
"C:\Program Files\COMSOL42\bin\win32\comsolcompile" -jdkroot "C:\Program Files\Java\jdk1.6.0_43" %1
And yes, I did reset the history before saving my .mph file as .java file. As this model was partly created editing .java files and creating those several spheres though "for" loops, I'll try to re-loop this file instead of this de-looped version that results from COMSOL's save as feature. But, I still waiting for a solution for my first problem - the problem with very small thickness of layer compared to the radius, as that solution would be much more natural and easier to model through the rest of the definitions.
If you have any ideas beside which I had here, please help.
Thanks.
EDIT:
Even the cleaned file exported from COMSOL to .java file to my model, without even editing it, I get the same error during compilation: code too large exception. Is there any workaround for that?
ERROR compile.java:15: code too large [com.comsol.logger
]
ERROR public static Model run() { [com.comsol.logger]
ERROR ^ [com.comsol.logger]
ERROR 1 error [com.comsol.logger]
ERROR Exception:
com.comsol.util.exceptions.FlException: Program did not exit normally
Messages:
Program did not exit normally
[com.comsol.logger]
got this code too large exception, and I'm worried that this is a Java compiler limitation (well, looks like there's more from Java for me to hate) based on the results I got when googled that.
This is the .bat file I use to compile my files, where %1 is the first argument to this batch that corresponds to the .java file path.
"C:\Program Files\COMSOL42\bin\win32\comsolcompile" -jdkroot "C:\Program Files\Java\jdk1.6.0_43" %1
And yes, I did reset the history before saving my .mph file as .java file. As this model was partly created editing .java files and creating those several spheres though "for" loops, I'll try to re-loop this file instead of this de-looped version that results from COMSOL's save as feature. But, I still waiting for a solution for my first problem - the problem with very small thickness of layer compared to the radius, as that solution would be much more natural and easier to model through the rest of the definitions.
If you have any ideas beside which I had here, please help.
Thanks.
EDIT:
Even the cleaned file exported from COMSOL to .java file to my model, without even editing it, I get the same error during compilation: code too large exception. Is there any workaround for that?