In three fin_3d example, the fin are defined in a particular (x, y, z) directions. However, after I switched the direction definition,
I found that the fin.repeat method doesn’t work anymore?
So should I define all the geometry in the same directions as the fin examples?
Hi @cxi1
If you want to rotate the fins of the heat sink, you’ll also likely need to adjust the repeat method as well which requires you to specify the number of copies in a given direction. Using simple scripts like in the geometry section of the user guide and var_to_polyvtk is a good way to rapidly debug geometry objects.
Hi @ngeneva ,
I noticed an issue with the geometry module. Previously I define the heat sink dims using units of mm (scale = 1000), and the below code works well with heat sink creation and also heat sink bottom surface sampling for heat source location. However, after change geometry to SI units of meter (scale = 1), the codes below doesn’t work anymore, it can’t sample the bottom surface and it gives me the error message :
" File “test_geometry.py”, line 48, in
sample= heat_sink.sample_boundary(nr_points=4000, criteria=Eq(z, heat_sink_base_origin1[2]))
File “/home/cexi1992/anaconda3/envs/modulus_22.09/lib/python3.8/site-packages/modulus-22.9-py3.8.egg/modulus/geometry/geometry.py”, line 479, in sample_boundary
assert np.sum(curve_areas) > 0, “Geometry has no surface”
AssertionError: Geometry has no surface
"
Code:
from sympy import Symbol, Eq, tanh, And
import numpy as np
from modulus.geometry.primitives_3d import Box, Channel, Plane, Cylinder
from modulus.utils.io.vtk import var_to_polyvtk
x, y, z = Symbol(“x”), Symbol(“y”), Symbol(“z”)
scale = 1000
heat_sink_base_origin1 = np.array((-0.098, -0.065, 0.018))*scale
heat_sink_base_dim1 = np.array((0.076, 0.060, 0.005))*scale
fin_origin1 = heat_sink_base_origin1 #np.array((-0.098, -0.065, 0.0226))*scale # base=4.6 mm
fin_dim = np.array((0.002, 0.06, 0.0174))*scale
total_fins = 10
heat_sink_base = Box(
heat_sink_base_origin1,
(
heat_sink_base_origin1[0] + heat_sink_base_dim1[0], # base of left heat sink
heat_sink_base_origin1[1] + heat_sink_base_dim1[1],
heat_sink_base_origin1[2] + heat_sink_base_dim1[2],
),
)
fin = Box(
fin_origin1,
(
fin_origin1[0] + fin_dim[0],
fin_origin1[1] + fin_dim[1],
fin_origin1[2] + fin_dim[2],
),
)
gap = (heat_sink_base_dim1[0] - fin_dim[0]) / (total_fins - 1) # gap between fins
fin_original = fin
for i in range(total_fins - 1):
fin = fin.translate([gap, 0, 0])
fin_original = fin_original + fin
heat_sink = heat_sink_base + fin_original
sample= heat_sink.sample_boundary(nr_points=4000)
var_to_polyvtk(sample, “./heat_sink”)
bottom= heat_sink.sample_boundary(nr_points=4000, criteria=Eq(z, heat_sink_base_origin1[2]))
var_to_polyvtk(bottom, “./heat_sink_bottom”)
"
Do you know why it happens? Is this because that geometry module only accept floating point values up to a certain degree?
If this is the case, what should I do now? Defining all the geometry in unit of “mm” ? But what am I supposed to do with the corresponding changes with the unit of fluid density, velocity, etc to make them consistent?
Thank you again for your support,
Ce
This error typically arises when you’re trying to sample geometry that has some sort of criteria or form that has no volume / area (e.g. I have a box that’s has points [(0,0), (0,1), (1,0), (1,1)] and a criteria of x > 1.5). The geometry for this example was specifically build for this and I would treat it as pretty rigid. It’s likely there’s some hard coded values that are conflicting with the scale parameter somewhere.
@ngeneva
I did some debugging yesterday, it seems there exist rounding errors associated with the coordinates definition.
If I set heat_sink_base_origin1 = (-0.098, -0.065, 0.018) to be (-0.098, -0.065, 0.0182). The error message is gone.
Pretty strange but it works anyway.
I recently switched the coordinate system in my code to better align with my application’s requirements. It seems that some of the GPU functions, particularly those related to memory allocation and data transfer, are not behaving as expected with the new coordinate system. I suspect this might be causing issues with the CUDA calls, but I can’t quite pinpoint the problem.