[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Coupling with EES



Dear TRNSYS Users,

I have encountered a problem while running a Deck that uses Type 66. Instead
of getting output values from the EES program I get the EES input values
that where pasted on the CLIPBOARD by TRNSYS. I have taken a look at the
Type 66 source code and think this problem might have something to do with
the following lines, specifically with the variable ICARD. I tried giving
this variable an index like "J" or "ICH" but I wasn´t sure about what I was
doing. Anyway, In my output files I got a value that at least was different
from the input values...but they still were not right!

*************
      J=1 ! same as the section in READIN that converts a string to a bunch
of numbers
	ich=1
415   CONTINUE
      IF (ICH.GT.512) THEN
C         FLAG ERROR AND RETURN IF CARD EXHAUSTED
          return 1
      ELSE IF (ICARD(ICH).EQ.BLANK.OR.ICARD(ICH).EQ.COMMA.
     .         OR.ICARD(ICH).EQ.EQSIGN.OR.ICARD(ICH).EQ.TAB.
     .         OR.ICARD(ICH).EQ.QUOTE.
     .         OR.ICARD(ICH).EQ.CHAR(0)) THEN
        ICH=ICH+1
        GOTO 415
      ENDIF

      CALL STRNUM(ICARD,RNUM,ICH,IERRED)
      IF (IERRED.GT.0) THEN
           write(luw,*) "error converting clipboard data to numbers"
	     call mystop(1001)
	     return 1
      ELSEIF (IERRED.LT.0) THEN
C  .      CHARACTER DETECTED why is EES doing that?
           write(luw,*) "clipboard data contains a character"
	     call mystop(1001)
	     return 1
      ELSE
          out(J)=RNUM
      ENDIF

      J=J+1
      IF (J.GT.maxout) RETURN 1
      GOTO 415
*****************

Type 66 is referenced in the deck file like this:

******
* Model "Type66" (Type 66)
*

UNIT 20 TYPE 66	 Type66
INPUTS 3
* Equa-2:Tc ->Input-1
Tc
* TYPE9a:Output 8 ->Input-2
5,8
* Equa-2:Qp_aux_n ->Input-3
Qp_aux_n
*** INITIAL INPUT VALUES
0 0 0
LABELS 1
C:\EES32\EES.EXE C:\EES32\TRNSYS.EES
*******

This form differs somewhat from the one described in the Reference Manual
(no strings were given as initial values). This is probably due to the
modifications made in the Type 66 subroutine in Spring 2001.

Can anyone help me out?

Thanks in advance,
Juan Pablo de L. C. Salazar