Right. Thank you very much for your explanation and comments.

Your approach is the correct one.
There are a few caveats that could explain the discrepancies in the results (one should, of course, obtain the same current flux between anode and cathode regardless of the method used):

the surface used to compute the flux should intersect with all field lines between anode and cathode, once, and only once. An example might be a plane that cuts through the head, with one electrode on each side. Another possibility is to create a box that encloses one electrode. In your example, with the sponge, I think you might have current entering from one side and leaving through the other and would actually have expected a total flux of zero. the surface needs to be correctly discretized. For that, try to reduce the Minimum Edge Length property of the surface in the Explorer tree (after drag & drop), then Refresh Viewers, until the Total Flux value stops changing I am not sure what happens if the surface is also a boundary condition for the J field (as in the case of your electrode). Maybe there are some discretization issues there. In all cases, it often helps to visualize the flux of J on your chosen surface, by using the Surface Viewer

I hope this helps

For FDTD simulation, you will need to excite the plates by joining them with a wire (use the Sketch -> Lines tool), as if you were building a circuit. Leave a small interval open somewhere so that you can insert an edge source.

Hi Saya, "parameters" are by definitions input by the user. Their values, as well as their standard deviation or any other statistics, can therefore not be "found" by the program itself.
Maybe it would be clearer if you could provide an example.
best regards

@Sylvain Thank you. I will try your suggestions.

Thanks for your help.

By default, the LF solver use a single core of the CPU, so the total CPU usage can appear quite low if you have several cores.
In the "Solver" settings of the simulation, you can choose to use more than 1 core. This relies on the MPI library to parallelize the workload between different CPU cores.

The speedup you gain with MPI depends on many parameters, including discretization of the computational domain (e.g. number of grid cells) and hardware specs (e.g. available RAM). The only reliable way to know is to try on a few representative examples, with different number of CPU cores.

Note that the MPI parallelization requires specific license tokens. If you try and it fails with licensing errors, you can always request a trial license for this feature.

To get a meaningful answer to this kind of question, you would need to provide more detailed information: such as screenshots (you can copy/paste images into your posts), formula, numbers, etc...

I think that it would not be possible since you can only assign conductivity values for the voxels. Not the edges of the yee cell where the E-fields are computed. This basically means the absorbing boundary gets avaraged and won't work as you would want.

Hey,
Not entirely sure what you are referencing here, but you could sketch a line in your model environment (connected to the plates). Then in the simulation tab you can add this to the simulation you would like to run. Click on the multi-tree button in the menu bar and drag the line into the simulation. Specify that it is an "edge source". Then in the simulation go to the sources tab and fill in the frequency you want (27MHz).
As for the potential you want to set, you should just run the simulation and normalize the answer afterwards in the analysis tab.
Hopefully this is what you are looking for.

Hello

Thank you for the quick response. The client and server machine are the same. I checked about the disk performance. Yes, you are right, the disk write speed is very slow. That's why they are taking very long time to submit the job. I will have to replace the disk i guess.

Thank you
Suchit Kumar

You may want to make sure that the endpoints of your source are precisely the corner points of your bowtie. Two neighboring points may appear as one in the GUI, but may be different in the lower decimals. In such a case, you will get a very small mesh step.

An alternative to remedy this is to use a source that is aligned with the grid and modify the tips of the patches of the rotated bowtie such that they touch the tips of the source. Close to the feed, this should not matter a lot. You can check this by comparing the feedpoint impedance and the near-field to those of your original simulation.