Hybrid Car – More Fun with Less Gas

Night ventilation - Page 5

register ::  Login Password  :: Lost Password?
Posted by nicksanspam on November 27, 2006, 7:39 pm
 

Frequently :-)


I suggest you look again.

Nick


Posted by daestrom on November 27, 2006, 11:50 pm
 


You're a broken record.
I suggest you go back and look at the code you posted at the top of this
thread.

I suggest you get your head out of your a__ and actually read what some of
the other people have posted before replying to them.  Including the
complete listing of your original post.

I suggest you stop posting GW-BASIC code until you can actually understand
the stuff you've already posted.  You *obviously* have not gone back and
looked at your own post, yet you continue to waste our time with "I suggest
you look again."

I suggest you take me up on my request and tell us *all* what line of code
in your original posting takes into account the solar energy input.

I suggest that if you think your code *does* account for solar energy,
you've invented your own physics that doesn't comply with any of that
'hundred year old physics' you're so fond of.


Here, let's take your original code, line by line.


A derivation of the value of PI.  Nope, no solar energy input there.


A conversion factor to convert hours of the day into radians for use in a
sin function.  It will be used in line 140.  That line occurs inside two
nested loops, so to save computational time, you perform some of the
calculation here and save the intermediate results in variable W.  Nope, no
solar energy input there.


The capacitance of the house.  This variable is only used in line 190.  It
doesn't really save any computational time to have it here, but then it
doesn't really cost anything but a word in memory, so what the heck.  Nope,
no solar energy input there.


Labeled as 'conductance' although it could include the overall effects of
air infiltration (other than the ventilation panels) to give an overall heat
transfer coefficient with some outdoor temperature.  Has to be for
temperature-differential based heat transfer since it is F in the
denominator of the units.  This supposition is also supported by how it is
used in line 150 for heat losses.  It's only used in line 150, but like the
variable 'C' above, it only costs a word in memory.  Nope, no solar energy
input there.


Described as the cross-sectional area of the ventilation inlet.  Used in
line 170. Nope, no solar energy input there.


The height between the lower and upper vents.  Also used in line 170. Nope,
no solar energy input there.


Described as electrical energy dissipated inside the house over a one month
period.  Presumably this is some 'average' usage for the house in question.
Seems high for July with no A/C, but not extreme.  Nope, no solar energy
input there.


Conversion of electrical energy dissipated in the house over one month to
BTUs and then converted to daily use by taking the total usage and dividing
by the number of days.  Oh, but July has 31 days.  Well, maybe the meter
reader came a day early.  Nope, no solar energy input there.


Calculate the average hourly usage from the average daily usage.  Pretty
naive to think that energy usage is 'flat' throughout the day and night.
Most people use more electricity when they are awake, but maybe Nick is a
'night-owl' and keeps the lights 'burning' 24 hours a day.  No wonder his
house overheats without ventilation.  Nope, no solar energy input there.


Average outdoor air temperature.  This is the dry bulb temperature of the
air taken from your data source.  It does not have solar energy input since
dry bulb temperature recordings are classically taken "in the shade and out
of the wind".  Nope, no solar energy input there.


Begin a ten day iteration to allow temperatures to stabilize.  Nope, no
solar energy input there.


Iterate on an hourly basis through-out the 'day'.  Nope, no solar energy
input there.


Calculate an hourly air temperature.  This assumes a nice sinusoidal
variation about the 70.2 F with a peak at 80.7 F and a minimum at 59.7 F.
It has a phase-shift error, it predicts the daily minimum at hour 18, a
daily maximum at hour 6 and 70.2 F at hours 0 and 12.  You could just print
out the hour with a phase shift the other way, but this error will make it
difficult to add any other 'hourly' variables, since it wouldn't be obvious
that H=6 is really local noon.  Nope, no solar energy input there.


A calculation to determine net heat energy in/out of the house.  Ah, now
*this* is where you would have a solar energy input *if* you had one, but
nope.  We have HGAIN, the hourly electrical energy dissipated inside the
house from line 100 and (T-TR)*G.  This second term is a temperature
difference (the hourly outdoor temperature calculated in line 140, and TR
the temperature of the house.  No sign anywhere of the temperature of the
sun's surface.  And the term G is the thermal conductance between the
interior and the exterior of the house.  Nope, no solar energy input there.
Too bad, this is the spot to add it in if you wanted to, but you didn't and
can't even seem to remember not doing it.


A simple if-check to turn off any ventilation if the house is cooler than
the outdoors.  This is accomplished by the cooler air inside the house
holding your plastic 'check-valves' shut.  If they are shut, we skip the
next two lines of code (that update Q based on the ventilation).  Nope, no
solar energy input there.


If we get to this line, it's because the GOTO in line 160 wasn't executed.
That would mean that the house temperature TR is not less than the outside
hourly air temperature T.  So the plastic 'check-valves' are not shut and a
formula taken from ASHRAE gives you an approximation of vertical air flow
from the thermo-siphon effect.  Nope, no solar energy input there.


Adjust the net energy gain/loss for the house by the amount of air flowing.
There is an implicit assumptions in this line of code that a cubic foot of
air has a heat capacity of 1/60 BTU/F.  Not too bad, but not real close.  So
for every cubic foot removed in a minute, 60 cubic feet are removed in an
hour, and that amounts to 1 BTU/F.  So multiply air flow in CFM by the
temperature difference between the incoming and outgoing air to get the
amount of heat carried off by that air.  This also assumes the density of
the outside air is the same as inside air (something we *know* to not be
true, otherwise there would be no circulation).  But to a 'first-order'
approximation, eh, it works.  But nothing to do with solar input.  Nope, no
solar energy input there.


Adjustment of the house interior temperature using the amount of heat
added/removed and the capacitance of the house.  Nope, no solar energy input
there.


A simple if-check to print out the results on day 10 only, and only print
out the data on 'even' numbered hours, to save printout space?  Nope, no
solar energy input there.


Iterate to the next hour and the next day respectively.  Nope, no solar
energy input there.

Look again Nick, you left out solar energy inputs to the house.  You've been
told this by others as well as myself and all you can do is try a rather
lame, "I suggest you look again."

If it's really there, you would have replied with the line number and an
explanation of how the calculation works (as I have asked you to do several
times).  Yet you haven't.  So rather than fess up and admit to an error, you
try and remain arrogant about it, and hide behind some aloof, "I suggest you
look again.".  It may work once or twice, but your constant repeating
without explanation is showing you to just be an arrogant fool that can't
admit his own mistake.

I'm done with you.  I've given you suggestions to improve your coding, but
you've ignored them.  I've asked you where you think solar energy is
factored into your code but you've ignored such requests.

But I'll continue to point out that your code is *not* a valid model.  It
doesn't predict real-world behavior.  You are selective in what
terms/factors to include and I can only conclude at this point that it's a
deliberate move on your part to bolster your idea/viewpoint.  It's obvious
to me that you want to 'sell' your ideas and you're trying to use 'selective
physics' to make them look better than they really are.  If you were being
paid for your idea, some folks would call it fraud.

Which do you fall under, "Liars, Damn Liars, or Statisticians"?

daestrom


Posted by nicksanspam on November 28, 2006, 10:48 am
 
I suggest you be less arrogant and more polite and look more carefully for
the phrase "unshaded windows."

Nick


Posted by daestrom on November 30, 2006, 11:13 pm
 

Speaking of 'arrogant', maybe if you just answered the question about ten
posts back, others (including myself) wouldn't treat you so badly.  A
simple, "I assumed the 600 kWh/month that is listed as 'electric usage' in
line 80 also included whatever solar gain there might be."

But instead, you acted smug and replied with "you missed it", "look again",
and other rather arrogant replies.  In your leading paragraph you state,
"... be comfortable with no AC and 20 kWh/day of internal heat gain from
electrical use or unshaded windows."  I read line 80 in your listing as
'electrical usage' *or* unshaded windows.  Not both.  It's not my fault you
wrote conflicting statements.  Maybe you should consider a writing class at
your local college.

But you seem too arrogant to consider that your message is ambiguous and
unclear, despite the large number of folks that asked you where the 'solar
gain' is in your model.  Didn't it occur to you (your arrogance again) that
none of us considered that when you said, "...internal heat gain from
electrical use OR [emphasis added] unshaded windows.", what you really meant
was, "...internal heat gain from electrical use AND unshaded windows."
Pardon us for not reading your mind instead of only reading what you typed.
Yyou took the time to comment your code this time (an unusual event), and
commented line 80 to be " 'internal electrical use (kWh/month)", with no
mention of 'unshaded windows'.  So many of us felt that you were using 600
kWh/month as either the 'electric usage' -OR- the equivalent in solar gain,
not both.

If you had commented that it was "internal electric plus unshaded windows
(kWh/month)", then we would have seen that you meant "...internal heat gain
from electrical use AND unshaded windows."  But you didn't, and you didn't
bother to clarify yourself at all, despite several requests, you just sat
back, acting smug with "look again", etc...   Now, that's arrogance.  No,
you can't argue that, "Well, daestrom got 'snippy' with me, so I didn't
answer him".  You didn't answer anyone else that asked either (there were
several).  Do you really think the stuff you post is that clear and precise?
Arrogance again??

So, how did you arrive at the number 600 for both electric and solar
combined?  Electric would have just been read the meter for the month.  But
solar?  Or did you just read the meter for the month and 'fudge' it a bit
higher?

My usage in June/July/August without A/C ran about 500 kWhr/month the last
several years, so I suspect your number is pretty low.  Got an idea how much
solar gain from 'unshaded windows' really is for Rochester NY, or is that
just something you pulled out of someplace where the sun doesn't shine?

Still waiting to here how your idea compares with a version of your model
running with just 'open the window'

daestrom


Posted by Tony Wesley on November 30, 2006, 11:33 pm
 
daestrom wrote:
[...]

Let me answer that for you.

sx=0:sy=0:sxx=0:sxy=0:syy=0
for i=1 to n
   sx=sx+x(i)
   sy=sy+y(i)
   sxx=sxx+x(i)*x(i)
   sxy=sxy+x(i)*y(i)
   syy=syy+y(i)*y(i)
next i
b=(sxy-sx*sy/n)/(sxx-sx*sx/n)
a=(sy-sx*b)/n
r=(sxy-sx*sy/n)/sqr((sxx-sx*sx/n)*(syy-sy*sy/n))
IF ym > 0! THEN above = 1 ELSE above = 0
'used later to classify non-risings
DO
'ym = sinalt(iobj%, date, hour - 1, glong, cl, sl) - sinho(iobj%)
y0 = sinalt(iobj%, date, hour, glong, cl, sl) - sinho(iobj%)
yp = sinalt(iobj%, date, hour + 1, glong, cl, sl) - sinho(iobj%)
xe = 0
ye = 0
z1 = 0
z2 = 0
nz% = 0
quad ym, y0, yp, xe, ye, z1, z2, nz%
SELECT CASE nz%
CASE 0 'nothing  - go to next time slot
CASE 1                      ' simple rise / set event
IF (ym < 0!) THEN       ' must be a rising event
utrise = hour + z1
rise = 1
ELSE                    ' must be setting
utset = hour + z1
sett = 1
END IF
CASE 2                      ' rises and sets within interval
IF (ye < 0!) THEN       ' minimum - so set then rise
utrise = hour + z2
utset = hour + z1
ELSE                    ' maximum - so rise then set
utrise = hour + z1
utset = hour + z2
END IF
rise = 1
sett = 1
zero2 = 1
END SELECT
ym = yp     'reuse the ordinate in the next interval
hour = hour + 2
LOOP UNTIL (hour = 25) OR (rise * sett = 1)
utrise = hm(utrise)
utset = hm(utset)
PRINT
PRINT "   "; obname$(iobj%)
' logic to sort the various rise and set states
IF (rise = 1 OR sett = 1) THEN   'current object rises and sets today
IF rise = 1 THEN
PRINT USING p$; utrise
ELSE
PRINT "    ----"
END IF
IF sett = 1 THEN
PRINT USING p$; utset
ELSE
PRINT "    ----"
END IF
ELSE              'current object not so simple
IF above = 1 THEN
SELECT CASE iobj%
CASE 1, 2: PRINT "    always above horizon"
CASE 3: PRINT "    always bright"
END SELECT
ELSE
SELECT CASE iobj%
CASE 1, 2: PRINT "    always below horizon"
CASE 3: PRINT "    always dark"
END SELECT
END IF
END IF


...the window thing is probably pretty good!


This Thread
Bookmark this thread:
 
 
 
 
 
 
  •  
  • Subject
  • Author
  • Date
please rate this thread