Andes speed calculation

[jd-lara]

I am currently using master in this simulation to test for a generation trip of generator No 5 at Bus 102, here is the set-up the raw and dyr files are in the attached zip file

import andes
ss = andes.run("FourBusMulti.raw",
            addfile="ThreeBus_multigen.dyr",
               setup=False)

ss.add("Toggler", dict(model='SynGen', dev="GENROU_6", t=1.0))
ss.setup()

ss.PQ.config.p2p = 0
ss.PQ.config.q2q = 0
ss.PQ.config.p2z = 1
ss.PQ.config.q2z = 1
ss.PQ.pq2z = 0
ss.PFlow.run()

ss.TDS.config.tf = 20
ss.TDS.config.criteria = 0
ss.TDS.run()
ss.TDS.load_plotter()
ss.TDS.plt.export_csv()

ss.TDS.plt.plot(ss.GENROU.omega,
                a=(0, 2, 3, 4),
                ytimes=60,
                )

However, the resulting frequency is this increasing line.

I am expecting to see something more like this which matches PowerSimulationsDynamics and PSS/e

Archive.zip

[cuihantao]

Hi Jose,

Thanks for reporting. It looks like an issue with ANDES. I will look into it and let you know.

[cuihantao]

@jinningwang It looks like an issue with GAST. One or multiple sign errors creat a positive feedback, which causes the frequency to rise even without any disturbance.

[jinningwang]

@jd-lara Hi, After inspection, it is caused by inappropriate GAST parameters VMAX and VMIN. After converting to the ANDES input file, those two parameters are set to be 0.5, and they limited the GAST.LAG to match the GAST.pout. Setting them to 1.1 and 0 can solve the issue.

@cuihantao Hantao, Should we consider some auto-correction for this?

Regards, Jinning

[cuihantao]

Thanks for the diagnosis and sorry for my wrong thoughts. Not sure why the auto parameter correction for upper limits did not catch this one. Can you look into that?

Regards, Hantao Cui On Apr 25, 2022, 3:48 PM -0500, Jinning Wang @.***>, wrote:

@jd-lara Hi, After inspection, it is caused by inappropriate GAST parameters VMAX and VMIN. After converting to the ANDES input file, those two parameters are set to be 0.5, and they limited the GAST.LAG to match the GAST.pout. Setting them to 1.1 and 0 can solve the issue. @cuihantao Hantao, Should we consider some auto-correction for this? Regards, Jinning — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[jd-lara]

@cuihantao I am not sure this is the root cause since in PSSe and in PSID we don't get any input errors.

[jinningwang]

Hi,

The bug is caused by that the LAG reaching the lower limit. I enabled the adjust_lower of GAST, so the limit can be autocorrected. For more information on limit adjustment, you can check https://docs.andes.app/en/stable/release-notes.html?highlight=adjusted%20limit#v1-5-7-2021-12-11

The fixed code can be found in the PR: https://github.com/cuihantao/andes/pull/319

Regards, Jinning

[cuihantao]

@jinningwang It's a separate issue. The immediate cause of the error is the wrong treatment of PSS/E dyr data for GAST. The fix is pushed to my develop.

@jd-lara After fixing the parser issue, the results are now the same as PSID:

[cuihantao]

The result looks pretty much like that from PSID but is slightly different in the magnitude:

[jd-lara]

Thanks @cuihantao, I will continue the testing once it's merged

[jd-lara]

The result looks pretty much like that from PSID but is slightly different in the magnitude:

That's probably right, we are chasing a bug in the governors that is creating relatively small differences in the frequency. Testing with ANDES is easier than with PSSe :)

[cuihantao]

Lol, thanks! Good luck with the bug chase! It could be both annoying and fun :)

My master branch is updated with the fix.