"Developer error" in Xyce output

[Michael Barnard]

I have been using Xyce on a particular problem involving YACC, and am repeatedly running into the following obscure error:

Developer error: Data not in directory: ( VP_3 , -1 )
 
It seems to be related to what terms show up in the mathematical expression for the BACC acceleration value.  In this case, Vp_3 is a component that is being used to measure the current in one of the inductors, and I've checked that it is properly listed in the net list.
Has anyone seen this before?

[xyce-users]

Sad to say, yes, people have seen this before, but very infrequently and only when something is very strange with their input.  The error is extremely obscure, and is a "developer error" because users are not ever supposed to see it, as it indicates a code problem.  And it is unhelpful enough that seeing the error message isn't enough to understand what is causing it.  Something in your netlist is somehow getting past early error detection and making it to a part of code that can't deal.

Is your netlist very large?  Any chance you could post it, or if it's proprietary, at least a relevant fragment including the BACC line you're using?  Diagnosing the problem might be more tractable in context.


 

[xyce-users]

On Friday, October 17, 2014 2:04:42 PM UTC-6, Michael Barnard wrote:

The BACC fragment should be fine:
Bacc  acceleration  0   V = {( 0
+ + I(XCoil1:Vc)*21*I(Vp_1)*DM_AC(v(z)+Poff+0*ZspaceP-0*ZspaceC)
+ + I(XCoil1:Vc)*21*I(Vp_2)*DM_AC(v(z)+Poff+1*ZspaceP-0*ZspaceC)
+ + I(XCoil1:Vc)*21*I(Vp_3)*DM_AC(v(z)+Poff+2*ZspaceP-0*ZspaceC)
+ + I(XCoil1:Vc)*21*I(Vp_4)*DM_AC(v(z)+Poff+3*ZspaceP-0*ZspaceC)
+ )/mass }
This is one of the shorter versions that will produce the error (I've been working with one 80 lines long that works).  I've tried re-shuffling the order of operation (which usually leads to the error flagging the XCoil#:Vc parameter instead of Vp_#) or re-grouping the terms (which sometimes works, but the way I have it above tends to work best).  

You're right, nothing about that looks wrong.  There must be something else hidden in the details of the rest of the netlist that is confusing things.

This will probably require the full netlist to diagnose the issue.  If there is sensitivity involved and you can't share the netlist on the public group, please contact the team via  the sandia.gov contact address on the web site, and we could arrange a way of communicating with you privately.  This "Data not in directory" error is so obscure and hard to trip that there's almost no way to diagnose it without access to an actual full test case that trips it.

Whatever the error in the netlist is, it should be getting caught before the code ever hits that unhelpful error condition, so this is something we ought to work on and get fixed.

 

[Michael Barnard]

Okay, I have a reduced netlist that still generates the developer error:

* Netlist  Developer error
.FUNC DM_AC(x) {TABLE(x,0,0)}
.TRAN 0 1
Lp_1    A_1      0p1  1
Rp_1    A_1    A_1b   1
Vp_1    A_1b    0p1      0
RP1gnd  0p1     0      1e+6
Lp_2    A_2      0p2  1
Rp_2    A_2    A_2b   1
Vp_2    A_2b    0p2      0
RP2gnd  0p2     0      1e+6
Lp_3    A_3      0p3  1
Rp_3    A_3    A_3b   1
Vp_3    A_3b    0p3      0
RP3gnd  0p3     0      1e+6
Lp_4    A_4      0p4  1
Rp_4    A_4    A_4b   1
Vp_4    A_4b    0p4      0
RP4gnd  0p4     0      1e+6
XC1  11_1 10_1 z dzdt GC1
Lc_1    11_1    10_1  1
.subckt GC1 L1 L2 z dzdt
Vc    L1      2       0
Rc     2     L2     1
Rgnd   0     L1      1e+6
.ends GC1

Bacc  acceleration  0   V = {( 0

+ + I(XC1:Vc)*I(Vp_1)*DM_AC(v(z))
+ + I(XC1:Vc)*I(Vp_2)
+ + I(XC1:Vc)*I(Vp_3)
+ + I(XC1:Vc)*I(Vp_4)
+ )}
YACC acc1 acceleration dzdt z v0=0 x0=0
.end

[xyce-users]

Thank you, that will help me to track down the source of the problem, or at least confirm the issue.

On Friday, October 31, 2014 2:16:37 PM UTC-6, Michael Barnard wrote:

Okay, I have a reduced netlist that still generates the developer error:

* Netlist  Developer error

[...]

[xyce-users]

Thank you, Michael, for the demonstration test case.  It is extremely helpful.

Unfortunately, all we can say at this point is that there is definitely a bug and it will take a while to unwind why it is happening.  We'll also want to go back through older releases and see if it is a recent bug --- the kind of thing you are seeing here was  certainly not a problem when the SAND report on which you're basing it was written, so it is possible the issue got introduced in the various refactors that have happened at a rapid pace since Xyce 5.3 (our last release before we open-sourced the code).

I was able to get your test case running by rearranging terms in the B source as you have mentioned before, but in theory nothing is wrong with the netlist as you wrote it --- what you have *should* have worked.

We'll enter this issue into our bug tracker and get a developer to start looking into what is wrong.  In the meantime, we apologize for the inconvenience.

[Michael Barnard]

Thanks.  In that case, is there anyplace I can go to get Xyce 5.3 for a Mac?

[xyce-users]

 

On Tuesday, November 4, 2014 11:57:25 AM UTC-7, Michael Barnard wrote:

Thanks.  In that case, is there anyplace I can go to get Xyce 5.3 for a Mac?

No.  Xyce 5.3 was not released as open source software.

It  might not help, either.  It was mere speculation that this is a new bug introduced since 5.3, I have not yet gone back to that old version to check.  

[xyce-users]

While we're unable to give you access to Xyce 5.3, I have just confirmed that this old version of Xyce did not give the "data not in directory" error that we're seeing in Xyce 6.2 on your circuit.  That will help us narrow down when the error was introduced so we can get it fixed for Xyce 6.3.

[xyce-users]

While it is unfortunate that it has taken this long for this issue to be resolved, we finally found the reason for the error in this circuit and fixed it this morning.  There was a bug deep inside the expression library that was causing it to mangle the expression.  Version 6.6 of Xyce (targeted for release in October) will have it fixed.

The issue turns out to be a mistake in how the expression library handled repeated terms with factors of the form I(instance) in a single expression.  This explains why factoring out the repeated use of I(XC1:Vc) made the error go away.  The fix was simple, finding it was not.