RL-GO in Plane Shell Not Allowed with Copper Shell
Altair EmployeeIs it possible to use the ray-launching geometric optics method with lossy materials? We are trying to model RF propagation in an empty airplane shell (consisting only of faces) but receive the following error when we change the shell material from PEC to copper with a thickness of 1 mm: ERROR 33858: Metallic triangles for ray-launching GO found with unsupported losses.
Is there any way to work around this error (in FEKO Suite 7.0)? I cannot post the plane model, but the shell can be thought of as an arbitrary closed surface inside of which there is a dipole antenna source. We would like to make the metallic shell have a thickness so to eliminate fields being generated external to the airplane with PEC as the shell material.
Answers
-
Hello riiily,
Lossy metals are not supported by RL-GO at the moment (also not in 2017.1.2). You don't need to specify copper with some thickness in your case, since PEC would be sufficient to ensure that the fields don't 'escape'. However, the dynamic range that you can expect for RL-GO is lower than a rigorous solution method such as MoM and even MoM has a dynamic range of about 60 dB (unless to take special care). The fields inside are still accurate even with a dynamic range of 60 dB.
Most importantly, it is not recommended to use RL-GO for closed PEC structures.
0 -
Thanks JIF,
To clarify, by dynamic range do you mean the ratio between the maximum signal value simulated and the minimum accurate signal value simulated?
I have run a simple simulation with RL-GO modeling of an electrically large PEC cube filled with free space and having a dipole antenna at the center of the cube and do obtain some non zero electric fields outside the PEC cube which not obtained using MoM to solve the same model. How inaccurate is RL-GO for (large) closed PEC structures? For what kinds of simulations will RL-GO not converge to the full-wave solution (or adequately approximate it)? Would MLFMM or UTD be a better solver method for these structures? Are these issues inherent to FEKO's implementation of GO or to the GO method generally? I have been told FEKO's implementation involves using ray tracing to compute surface currents generated by the impinging of rays on surfaces and from those surface currents, all other requested outputs. Is this true? I would have thought FEKO's RL-GO implementation would have been based more on computing desired outputs from the ray paths directly (i.e., more rays intersecting a given area of say, a near field request plane, directly translates to greater field strengths).
I have tried using the MLFMM method on a scaled down model of our plane (which I've attached) but receive the following error on attempting to solve the model: ERROR 832: Segmentation rules have been violated (two triangles touch without a common edge). The plane has been scaled down by a factor of twenty. I did not receive this error on an unscaled model of the plane but instead ran out of memory. Do Scale transformations often produce incorrectly connected models? I believe I properly scaled down all of the plane geometry components so they are scaled with the user-defined variable 'scale' so as to maintain the same relative geometry.
How can this error be worked around? We are using an imported SolidWorks file for the plane shell. I have tried using the Simplify transformation on all of the geometry import components of the scaled plane assembly but receive the same errors upon simulation. I also tried uniting the simplified geometry components but doing so caused many of the geometry import components to visually disappear (unless selected in the Model Tree) and to not be meshed. I also tried uniting the plane import geometry components without first simplifying them and received another error: ERROR 17448: Geometry union failed.
0 -
/emoticons/default_ohmy.png' srcset='/emoticons/ohmy@2x.png 2x' title=':o' width='20'> Many questions... I hope I have answers for all of them.
Altair Forum User said:To clarify, by dynamic range do you mean the ratio between the maximum signal value simulated and the minimum accurate signal value simulated?
Yes, that is what I mean by dynamic range. This is particularly important when you are trying to simulate high shielding effects. Lets consider a closed PEC cube with a source on the outside. The MoM will calculate the currents on the surface of the cube and the sum of all the currents + the outside source have to cancel inside the cube in order to have a zero field on the inside. Due to different mesh elements and the basis setup on these elements, there is a limit to how well these can cancel. If you now change the model to have a very small hole or slit, the accuracy of the very small fields on the inside will depend on how accurately the fields cancel and that is the dynamic range limit. Using SEP add magnetic currents to the model and allows a better representation and higher dynamic range (and double the unknowns).
Altair Forum User said:I have run a simple simulation with RL-GO modeling of an electrically large PEC cube filled with free space and having a dipole antenna at the center of the cube and do obtain some non zero electric fields outside the PEC cube which not obtained using MoM to solve the same model. How inaccurate is RL-GO for (large) closed PEC structures?
I'm not an RL-GO expert, but I'll try to give you an answer. Similar to the problem above where the MoM currents had to cancel to get zero field everywhere inside the cube, for the problem above the currents (for MoM) or ray contributions (for RL-GO) need to cancel to get zero field outside. Since MoM is a full wave solution, I would expect it to be much more accurate than RL-GO. For RL-GO, you have rays that bounce around inside the structure and at each reflection (or transmission) it calculates a field contribution due to that ray and then reflects to the next point. As the ray travels, it becomes wider and wider. At some point the interaction is small enough and the ray tracing stops. The sum of all the field contributions of all the rays now need to add up to zero field outside. To me it is quite clear that things won't easily add up as well as for MoM (or any full wave solution method). The fields in a closed PEC structure are also more dominated by modes being excited in the structure and for all the field contributions from all the rays to correctly add up for these modes intuitively feels like a tall order. This is why I would not recommend RL-GO for closed PEC structures. If there are losses that absorb the rays after a few interactions, then I would again say that RL-GO is applicable.
Altair Forum User said:Would MLFMM or UTD be a better solver method for these structures?
MLFMM is a full wave method, like MoM, and would be a good solution, if your problem is not electrically too big. MLFMM does have an iterative solver (due to it having a sparse matrix) that could result in convergence problems, but it is still a full wave solver that will take all the interactions into account.
I suspect UTD will have similar problems to RL-GO, but I have not tried this. Maybe someone else on the forum has more experience with it.
Altair Forum User said:Are these issues inherent to FEKO's implementation of GO or to the GO method generally?
This is not restricted to the implementation in FEKO. I would use the same argument for an ray based method (definitely the methods bases on the original SBR - shooting and bouncing rays).
Altair Forum User said:I have been told FEKO's implementation involves using ray tracing to compute surface currents generated by the impinging of rays on surfaces and from those surface currents, all other requested outputs. Is this true? I would have thought FEKO's RL-GO implementation would have been based more on computing desired outputs from the ray paths directly (i.e., more rays intersecting a given area of say, a near field request plane, directly translates to greater field strengths).
It calculates a field contribution at every ray interaction that is equivalent to (or similar to) calculating the current at the interaction point. It does not actually calculate the current though. In that respect it is the same as (or rather equivalent to) what PO does to calculate the interaction. Maybe think of it as an optimised multiple reflection PO implementation - not sure if thinking about it like that helps or makes it worse.
RL-GO is based on the original SBR (shooting and bouncing rays) and rays are shot, bounce around (adding their contribution) and then when they reflect to free space (not hitting anything) or become to small, they are discarded. The effect the rays have on the answer is captured by the contributions that were calculated at each ray interaction point (because of the equivalence principle). Thus, the fields are not calculated from the rays directly as you described.
UTD on the other hand uses ray tracing where rays are traced from the source to the request point along multiple paths (the paths take into account the direct, edge and corner reflection / refraction effects).
Altair Forum User said:ERROR 832: Segmentation rules have been violated (two triangles touch without a common edge).
This error can be introduced by scaling, but is not common. Basically it means that there are two triangles that touch, but they only touch at a common vertex or they in intersect. You need to find the problem and ensure that the model is correct. Since the triangles don't have a common edge, no current will flow from the one to the other.
Looking at your model, the problem is that the faces have not been unioned or stitched to ensure connectivity. This could also cause some of the RL-GO problems since there would be gaps in the model where rays could escape. You were just lucky (or unlucky) that yo did not see this error for the non-scaled model. RL-GO will also not give an error, but your results would not be correct (or there is a chance it would not be correct).
Altair Forum User said:How can this error be worked around? We are using an imported SolidWorks file for the plane shell. I have tried using the Simplify transformation on all of the geometry import components of the scaled plane assembly but receive the same errors upon simulation. I also tried uniting the simplified geometry components but doing so caused many of the geometry import components to visually disappear (unless selected in the Model Tree) and to not be meshed. I also tried uniting the plane import geometry components without first simplifying them and received another error: ERROR 17448: Geometry union failed.
I don't know why Parasolid is not happy with those faces and resulting in ERROR 17448. I would recommend that you send the model and the problem description to the FEKO support team and ask them to investigate it (it will most likely require the model to be sent to Parasolid for investigation).
For your model, there is a solution. Rather use stitch instead of union. I tried it and it worked without problems. Once you have done that you will have to us a cut-plane to see inside, since CADFEKO does not currently allow you to hide a face within a part.
0 -
what does the ray magnitude in postfeko means? and how it is calculated?
0