Jump to content

Torben Voigt

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Torben Voigt

  1. Hi @sutton304803, You might want to try modelling the twisted pair cable like in the attached example (helix + coating): patch_twisted_pair.cfx
  2. Hi @Marcus Chang, For the corner reflector you're using PO, but with PO no multi-reflections between PO faces are taken into account. A corner reflector is THE classical example where PO is not feasible. Furthermore, the asymptotic methods (PO, LE-PO, RL-GO and UTD) are only feasible if the model is electrically very large, e.g. 20 lambda, bigger is better, but the corner reflector is only around 4 lambda. You should definitele use MoM / MLFMM here. Same goes for the sphere, which is only 3 lambda in radius. When calculating the scattered field of the reflector and the sphere correctly (MoM), the received power of the reflector is around 10 times higher than that of the sphere.
  3. Hi @Marcus Chang, If you get identical far field results for both, then I assume you have in addition "Calculate only the scattered part of the field" activated: This will in this model of course give the same results, as the sphere is the only scattering object. So, in both cases you will get the scattered field from the sphere surface.
  4. Hi @Marcus Chang, Unfortunately I'm not sure about the Matlab code. Maybe someone else (@mel, @JIF) could have a look? You can get the far field pattern of the reflected field of sphere by doing this: This will then only use the contribution of the surface currents of the sphere.
  5. Hi @Marcus Chang, Let check what you did: In horn_X band_190309.cfx you calculate and save the near field and the far field of the horn antenna. In FF source_PEC sphere_sphere surface NF source_190312.cfx you replace the horn by the near field data from 1. and to illuminate a PEC sphere. Here's mistake #1: The orientation of the near field is wrong (the horn is looking downwards): This would be correct: Mistake #2: The near field data is placed at z=0, while in model 1. it is placed at z=0.2138m. Around the PEC sphere you request a new near field to capture the radiated field from that sphere. Here's the mistake #3: The near field request has the same radius as the sphere, so the near field point are calculated exactly on the PEC surface. For acurate near field results a field point should not be closer than 1.5 x the edge length of the surface mesh. In temp_190313.cfx you compare the received power of an RX near field antenna and an RX far field antenna. The results are different because of mistake #2 and also because of warning WARNING 39270: A receiving antenna described by a far field pattern is positioned too close to a scatterer, far field condition not met. It says that that a source (the field of the PEC sphere) is too close to the RX far field receiving antenna. In general for far field sources (or receiving antennas) a far-field radius should be considered. I also decreased the increment beween the near field points of model 1. to ensure accuracy. The final results agree quite well: Note, with larger distance between source and RX antenna (or plane wave instead of the near field of the PEC sphere) the difference would be around 0.2 dB, because of omitting Warning 39270. The three new model files are attached: NF_vs_FF_RX_antenna.zip
  6. Hi @Bidisha Barman, Maybe you can make use of the "Scope" in the far field request. There you can select which faces/wires are taken into account for the far-field calculation. You could for example select only those faces from the one element you're interested in.
  7. Hi @Marcus Chang, I would need the *.cfx files to investigate.
  8. Hi @Marcus Chang, In the model where the near field is requested, the Start and End values of U are defined from positive to negative: Therefore when trying to use as near field source, you should rotate the workplane of the source (or of the field data) so that the orientation agrees with the original model.
  9. Hi @elaiyabharathi, The basics of Feko are easy to learn by having a look at the GettingStarted.pdf and the ExampleGuide.pdf (...\Altair\2018\help\feko\pdf). But of course feel free to attach a descrption of the geometry here and I will be happy to assist.
  10. Hi @FEKOFan, Connecting MTL cables with MoM pots is unfortunately not supported. MTL cables interact with the surrounding only via radiation/irradiation. What may be possible is to cumpute s11 of the dipole, save as touchstone file and include this in your CableHarness. Question: Why do you want to model the Balun? Applying a voltage source directly to your antenna would basically represent an ideal Balun. Just saw that you wrote the goal in the original post: If you want to simulate the effect of the actual cable as radiating object, you would have to actually model the feeding cable and Balun cable. This would of course be quite an effort. I will have to discuss with a colleague if there is a better way to do this.
  11. Hi @FieldForcer, Mesh IDs are only present in POSTFEKO. They are shown if you press Ctrl+Shift ('snapping keys') and move the mouse over a triangle in a 3D view. The geometry is not present in POSTFEKO. In CADFEKO there is no connection between mesh and mesh IDs (these are created during solving). Solve your Skull model and look at the surface currents in POSTFEKO Save the model under different name in CADFEKO Delete / Exclude those areas of the geometry where the surface currents are lower than your desired threshold (compare with POSTFEKO). (you can e.g. add cuboids and then subtract them from the skull, use 'Split', etc.) Solve the new model and read the total surface in the out file.
  12. Hi @FieldForcer, I don't think there is a direct solution for this in either CADFEKO and POSTFEKO. FEKO does compute the total surface of all mesh elements and reports in the out file. But users can't select certain triangles and calculate that surface only. One possible (and probably elaborate) workaround could be to create a second model where you exclude all faces where the currents are below a certain threshold. When simulation this reduced model, the total surface will be written to the out file.
  13. Hi @FEKOFan, You have to set the CableHarness to "Radiating" or "Radiating (taking irradiation into account)": If a source is applied to a cable, it must not be considered purely irradiating, that's why the error occurs.
  14. Hi @FieldForcer, You're right, sorry. Seems I confused things. In the *.os file the center of the mesh triangles is written. The ID of each triangle can be found in POSTFEKO by using "Find elements". The only way to find out the positions of the vertices of each triangle would be looking up in POSTFEKO. By using "Ctrl+Shift" you can snap the cursor to vertices and read the coordinates in the bottom line. Could you describe why exactly you want to know the vertices? Maybe there is a different way to achieve your goal.
  15. Hi @FieldForcer, The location of the three vertices is given in the *.os file: 1st column: mesh triangle ID 2nd column: vertice x coordinate 3rd column: vertice y coordinate 4th column: vertice z coordinate In POSTFEKO you can find a triangle by its ID:
  16. Hi @BrianFEKO, Any kind of port calibration would have to be done manually, e.g. with the help of lua scripting in POSTFEKO (e.g. adjusting S11 with some calibration model). Unfortunately I'm not an expert on this.
  17. Hi @BrianFEKO, A region is created when faces form a fully closed volume. As soon as a region is present you can define the properties inside (e.g. set medium to some dielectric). The solver (MoM as default) will then use the Surface Equivalence Principle (SEP) to represent the region. I.e. the faces do behave as if there'a volume, without actually havin to mesh the volume. A surface mesh is sufficient. Note, one can also use Volume Equivalence Principle (VEP) instead of SEP. In that case the volume is discretized in tetrahedras. If not using MoM, with FEM geometry is also meshed with tetrahedras, with FDTD the whole problem is discretized with voxels (cuboids). In your model, the substrate is modelled with panar Greens functions instead of a volume. That's a very efficient method for printed structures, because the substrate won't require a mesh. In my graph you se the real part of the input impedance of VoltageSource1. De-embedding unfortunately isn't supported directly in FEKO. It's under development but unclear when it will be available.
  18. Hi @Villcent, The model Sphere_4mm_MLFMM.cfx has 4,860,384 mesh triangles, which means 7,290,576 unknowns in that case. Your simulation was terminated due to missing main memory. When you started the simulation 120.696 GByte were available. For an MLFMM simulation with 7,290,576 unknowns and 24 paralle cores you can expect the required memory to be around 250 - 350 GByte (with the given settings). What @mel wrote are basic steps to reduce the required memory (less mesh triangles, preconditioner SPAI, less parallel cores). In your case, I doubt this will be sufficient. Regarding the mesh size I would agree that lambda/6.5 shouldn't be a problem for RCS calculation. But I wouldn't go much lower than that. At some point you will have to accept that your hardware isn't sufficient anymore. What users then do is switch to FEKO's asymptotic methos (RL-GO, PO (LE-PO), UTD). Please note that these are obviously not full-wave methods anymore and you will do some approximations. Both RL-GO and PO(LE-PO) won't compute currents in the shadow regions, UTD is not possible for RCS since both source and field point are in infinite distance. To see if there is a significant deviation with asymptotic methods one would compare e.g. PO (LE-PO) with MLFMM where the hardware is still sufficient. If results agree sufficiently here, they will most likely agree even better at higher frequencies. For now I would suggest to try Sphere_4mm_HOBF.cfx and also Sphere_4mm_MLFMM_coarse_SPAI.cfx. In the letter I changed the mesh size to lambda/6.5 and chose SPAI as preconditioner.
  19. Hi @Villcent, In your model the ratio of highest frequency to lowest frequency is 500(!). This means that the mesh size is by factor 500 too small for the lowest frequency. The efficiency of the MLFMM suffers a lot from too small mesh elements. I would recommend to either divide the model in several models, so that the ratio is not bigger than 3. Here: 2 GHz- 6 GHz 6 GHz - 18 GHz 18 GHz - 54 GHz 54 GHz - 162 GHz 162 GHz - 486 GHz 486 GHz - 1 THz or (preferred) solve the model with MoM with HOBF (Higher Order Basis Functions) Also I would recommend using adaptive frequency sampling instead of linear spaced discrete frequencies. I'm sure this will lead to far less frequencies while having the same RCS result. This is how I would try it: RCS_Sphere_HOBF.cfx
  20. Hi @BrianFEKO, I think the model is set up correctly. And I also think the results are expected. A microstrip of these dimension should give an impedance of 50.75 Ohm. I think that slight changes of impedance with frequency are expected for microstrip lines: Best regards, Torben
  21. Hi @FieldForcer, The coordinates represent the center points of the mesh triangles. Best regards, Torben
  22. Torben Voigt

    mesh error

    Hi Teju, Seems like you have several if not lots of intersections in your mesh. I think attaching your model (*.cfx) would really help solving this problem.
  23. Hi @FEKOFan, you can of course always imitate the physical real-life scenario. Means that you physically model the coaxial cables. Since this would mean some computational effort die to lots of mesh triangles, you may use a TX line in CADFEKO: This can be placed between two ports and will act as if a piece of cable would be present. Only that it's not a scattering object, it's rather a black box. I did't yet check the feasibility of this approach. Do you think this could be useful? Best regards, Torben
  24. Hi @FieldForcer, You can "allow" FEKO to remesh your imported mesh by clicking on Use model mesh:
  25. Hi @FieldForcer, A wire is considered thin if r is roughly smaller than l/4. I'm not sure if I understand correctly what "loop" you are referring to. I only see a folded wire (monopole) with a differential port at one end. Again, the feed is pretty unrealistic, could it be that the one side of the port should be connected to an infinite PEC plane? Why do you expect the Gain to be zero in the y-direction? Maybe it would be easier if you could just share the design which you are trying to model?
  • Create New...