HFSS and Maxwell were made by Ansoft in the last century, and there actually were little problems with them. You could always trust the simulation provided by those systems.
However after Ansoft was absorbed by ANSYS, nothing was improved in solvers from engineering point of view. Instead some crazy non-scientific poorly documented things were introduced, probably programmed by game and CGI designers without any thoughts of engineering application.
One of the craziest thing I discovered lately it ANSYS's "closest point interpolation".
What is the "closest point" value, you may guess? Well, I think it is obvious - a value of the point found closest to the coordinate of the interest.
It would be a very good approach feeding the discrete precalculated input fields, or material parameters for precisely simulating complex designs.
However what does ANSYS think about the closest point values!? You may be surprised.
Below, I show you a test of the clp() function, which SHOULD find a value of the closest point from the dataset "$dataset" for every mesh node with coordinates XYZ.
It should be placed in the material editor, in any property cell as clp($dataset, X,Y,Z).
According to manual, X,Y,Z, are provided in SI units, i.e. in meters. The output should be in the dataset units, but it is not, recognized by HFSS on practice. So I recommend making it unitless, and multiply by the desired unit, like clp(...)*1cel.
Now I define a simple dataset with a script:
dim pushdata()
redim pushdata(1) 'generate the data incrementally in dynamic dataset
pushdata(0)="NAME:Coordinates"
pushdata(1)=Array("NAME:DimUnits", "", "", "", "") 'in meters
for x = -1.1 to 1.1 step .1 'in millimeters
for y=-1.1 to 1.1 step 0.1
for z=-1.1 to 1.1 step 0.1
redim preserve pushdata(ubound(pushdata)+1)
pushdata(ubound(pushdata))=Array("NAME:Point", CDbl(x/1000), CDbl(y/1000), CDbl(z/1000), 1) ' see that "1" in the end. it is a value of "1" inside the Unit-BOX
if ((abs(y)>=1) or (abs(x)>=1) or (abs(z)>=1)) then
pushdata(ubound(pushdata))=Array("NAME:Point", CDbl(x/1000), CDbl(y/1000), CDbl(z/1000), 0) ' see that "0" in the end. it is a value of "0" AROUND the Unit-BOX
end if
next
next
next
oProject.EditDataset "$Dataset", Array("NAME:$Dataset", pushdata) 'write the dataset to HFSS (ANSYS EDT))
Now lets see what the clp() function reads out from the dataset, and substitutes to material properties:
See the yellow and red lines on the plot below.
Obviously, those are NOT ones(1), and NOT zeroes(0), as one would expect.
I do not know what is that, but it is not a simple bug. I checked it in ANSYS EDT 2021 R1, and R2, both. It is a way how the programmer's head works.
Crazy stuff.
And we are forced to pay hundreds of thousands (some organizations pay millions) of Dollars for that, risking the corporate security btw. Because EDT is a security hole requiring Internet connection to work, and providing a backdoor for ANSYS, and anyone who could exploit that, to your system.
Andrey Porokhnyuk
Ansys Maxwell is essentially an electromagnetic field solution for electric machines, transformers, wireless charging, permanent magnet latches, actuators, and other electromechanical devices. It can solve magnetic and electric fields that are static, frequency-domain, or time-varying.
In addition, take a look at this: https://forum.ansys.com/discussion/22480/problems-with-distributed-memory-simulations-in-ansys-edt-hfss-2020r1
Ansoft(! not Ansys, because they did not add much beyond tweaking and screwing) Maxwell goes beyond machines, because first of all, it is a magnetic field and eddy current solver used for biasing and sensor design, and the magnetomotive force is the next stage.
Well, the distributed memory is an advanced system hurdle itself. I know that there are problems even when this mode succeeds to execute... Actually, EDT 2019-2021 has tremendous performance issues. Particularly HFSS lost its ability to scale performance with number of cores growing more than 4 per worker. ANSYS constantly lies about its ability to accelerate with GPU, forcing people buying overpriced Quadro and Tesla boards, which are not used, and soft-blocking from use cheaper Geforce boards where those could be used (as in version 2015)
But neither of that was affecting the data!
The problem I am telling today is the trust in the data which ANSYS's code prepares for simulation and gives out as a "solution". If I did not check it, I would still wander in the dark following the manual and trying to understand completely incorrect results!
Awful.
Ansys got so greedy, that it completely lost the sense of responsibility, thinking only about beating the money out of customers.
Dear sir:
Thank you for sharing this important and valuable information .....
With best wishes....
Andrey Porokhnyuk
Спасибо за ценную информацию. Мы тоже наблюдали странные заскоки in the Fields Calculator. Впрочем, это может быть просто недостаток нашего опыта. Спасибо.
Viktor Tikhonov, Field Calc is easy to check because it is linked to the report engine. With this thing, you can only check it by defining fixed coordinates for clp() inside the material editor, and observing the value in the material library. I found no other way to debug it.
Personally, I did not find serious problems in the Field Calc. But if you can share your experience, it would be good to know where the rakes are laid.
I should also warn you that X, Y, Z used in the material editor, are NOT IN METERS.
It is hard to say what are those, but these parameters are scaled NOT in meters, and those units are NOT "meter".
And there is no way to debug and see, what HFSS exactly substitutes for X, Y, Z.
Why I say that?
I tried defining clp($3Ddat, 0.001,0,0), and matched the circuit to VSWR close to 1. (yes, using that completely wrong data which clp() returns; so I tweaked the data)
I checked that with uniform dataset the value of clp($3Ddat, 0.01,0,0) is almost the same, and the matching is almost the same.
Then I defined clp($3Ddat, X,0,0). And got an unmatched circuit.
I tried clp($3Ddat, X/1000,0,0), ... X*1000, X/1meter, X/1000meter, X/1mm, and never got a matched circuit.
The spatially dependent parameter definition in ANSYS EDT is completely fake and does not work.
The interesting things go deeper. EDT 2021 is also spontaneously overwriting the material definition without notifying user.
When I try using clp($3Ddat, X*1meter, Y*1meter, Z*1meter), instead of simple X,Y,Z, which does not work, it magically starts calculating inside the pre-matched VSWR.
However, please note, that the 3D dataset is unitless.
And in that case the moment you start optimization in Optimetrics, HFSS rewrites the material property to some numeric constant it had derived by unknown criteria.
! Unbelievable !
But it rewrites, fakes your material definitions. And you do not even know about that!
Again, spatial clp() is one of the main features advertised by ANSYS today. And it is completely fake.
the crazy magical formula appeared to be clp($3Ddat, X*1meter/1meter,Y*1meter/1meter,Z*1meter/1meter)*1cel
- Without multiplying clp()*1cel (1 S_per_m, GHz, Oe, or anything you need), the value from clp() does not work in simulation. And simulation is wrong.
- Without multiplying X*1meter/1meter, clp() returns unknown value beyond the scope of imaginable. And simulation is wrong.
- When multiplying X*1meter, the material property is overwritten with some FAKE constant.
- When you follow the manual and use clp($3Ddat, X,Y,Z), it returns unknown value beyond the scope of imaginable. And simulation is wrong.
- - - By any means, clp() never returns a correct value from the dataset, rather makes some mathematically incorrect averaging with bizarre results.
just some snacks to your coffee: How Ansys EDT 2021 optimization works:
See the screen. It is a nonlinear "gradient" algorithm, which should follow the gradient. The correct answer is 98.
I suspect that Ansys knows the correct answer, but tries making as much work as possible before reaching the answer; which would stop the feed of electric power and precious time to that insatiable behemoth.
Thank you Andrey Porokhnyuk for sharing so valuable information. I am trying to understand the critical problem.
Dear Sovan Mohanty . Please see the interesting behavior of ETD rewriting the project clp definition to some decimal value, if some error happens, or the simulation is interrupted unexpectedly.
At this moment, I _suspect_ a multi-million fraud performed by ANSYS in attempt to win a competition against other EDA manufacturers. They offer customers a non-existing(fake) function, which is covertly substituting some averaged constant value during simulation, and writes back the functional definition when the simulation is finished. But if it is not finished, we may find that value magically appearing in the project definition, which should not be edited!
They are also very close to openly lying when promoting GPU acceleration in HFSS, but citing the acceleration in FLUENT, not HFSS or Maxwell, every time some numbers are required. In fact, GPU acceleration is unavailable in HFSS and Maxwell in most designs, except the simplest isotropic definitions. But ANSYS actively refuses explaining the detailed requirements to get the GPU acceleration active; thus forcing customers loosing money on purchasing non-optimal hardware which will never be used.
And I suspect, that it is a lesser part of the problem. As I said in another topic, recently customers were discovering some weird juggling with incorrect port impedance calculation, which may be just a bug introduced during the 25 years old code optimization, or may have deeper roots.
- Badges
- Science topic