Learning Forum

[AndyJP]

I remember this bug as long as I work with HFSS, starting from ver.11, and no one ever tried fixing it.

The parameter sorting splits at the next order and flips the opposite way, so you get 9,8,...1, (!) 99,98,97,96,95...11,10.

[Praneeth]

Please provide more information regarding your query to help us serve you better.
It looks like the parametric data has been imported into the tool. Kindly confirm the same.
Can you let us know what do you mean by "next order"?
Best regards

[AndyJP]

That is a list of solutions from the solution list.
But the problem is omnipresent in every table: the quantities a sorted correctly only within the same order (of the integer part). The next order of the quantity does not follow the sorting order(direction):.
In the decrease-sorted example above, the higher order of the numbers is appended to the tail, instead of going in the head of the list.
In every version of HFSS I ever seen. I was surprised to find it again in 2021R1.

[Praneeth]

I have tried to simulate your scenario but it is working fine for me.
Please share the snap shot of "sweep definitions" window for a deeper analysis.
Best regards

[AndyJP]

It is not in the sweep definitions. It is in the results. When you simulate a number of iterations, you have every iteration recorded with the parameters. And sorting by these parameters does not work as expected when the variation is larger then one order. This makes it very hard to find the iterations of interest.

[AndyJP]

BTW. There appears another bug when sorting parameters in optimetrics.
Out of the blue, just for checking, I tried creating a sweep of a capacitance from 1pF to 1uF, step 100pF. When pushing "C" label in the list, for sorting, the machine freezes. I thought that may be a temporary delay, but it is still there showing "not responding" for 4 hours without change.

[AndyJP]

That's how values are sorted in ascending and descending order:
If you don't see a problem here, you have big problems with counting numbers.