- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using CVF 6.6C - I know what the problem is, and I know how to fix it. I just don't get how the compiler parses the following:
O2_out_bits is correct, O2_out is not. How does the precedence parsing screw up the second example? (i.e., where are the implied parentheses?)
y(1) = mol_out * stream(flue_gas).multi_air.oxygen
y(2) = mol_out * stream(flue_gas).multi_air.CO2
y(3) = mol_out * stream(flue_gas).multi_air.SO2
y(4) = mol_out * stream(flue_gas).multi_air.NO2
y(5) = mol_out * stream(flue_gas).multi_air.HC_STEAM / 2.
y(6) = ash_flow * stream(clinker).fuelgas.oxygen / MW_O2
y(7) = ash_flow * stream(clinker).fuelgas.moisture / MW_H2O / 2.
y(8) = mol_CaSO4 * 2. ! needs O2 for SO3 => SO4
y(9) = mol_CaO / 2. ! overdoses on CaO
O2_out_bits = y(1) + y(2) + y(3) + y(4) + y(5) + y(6) + y(7) + y(8) + y(9)
O2_out = mol_out * stream(flue_gas).multi_air.oxygen
1 + mol_out * stream(flue_gas).multi_air.CO2
2 + mol_out * stream(flue_gas).multi_air.SO2
3 + mol_out * stream(flue_gas).multi_air.NO2
4 + mol_out * stream(flue_gas).multi_air.HC_STEAM / 2.
5 + ash_flow * stream(clinker).fuelgas.oxygen / MW_O2
6 + ash_flow * stream(clinker).fuelgas.moisture / MW_H2O / 2.
7 + mol_CaSO4 * 2. ! needs O2 for SO3 => SO4
8 + mol_CaO / 2. ! overdoses on CaO
O2_out_bits is correct, O2_out is not. How does the precedence parsing screw up the second example? (i.e., where are the implied parentheses?)
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Replace the dot field separators with %. Does it get it right now? We've had problems with this over the years, and some errors were discovered after CVF development ceased. (Intel Fortran has fixed them.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Steve - I remember reading about that problem on here!
Incidently, is it due to the use of 2. instead of 2.D0?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No. It's specifically due to using dot record field separators. The parser has complex rules for deciding whether this syntax is a field or an operator and sometimes it makes up its mind "too late" and messes up the precedence of other operators. We think that we have nailed all of these down in the current Intel compiler.
![](/skins/images/7FDC486457F5FB4D87FED5D8C92AC987/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page