Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Addresses #3216, wrong OS:Daylighting:Control rotation angle translated #3858

Merged
merged 6 commits into from
Feb 14, 2020

Conversation

joseph-robertson
Copy link
Collaborator

@joseph-robertson joseph-robertson commented Jan 21, 2020

Pull request overview

Please read OpenStudio Pull Requests to better understand the OpenStudio Pull Request protocol.

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

  • Model API Changes / Additions
  • Any new or modified fields have been implemented in the EnergyPlus ForwardTranslator (and ReverseTranslator as appropriate)
  • Model API methods are tested (in src/model/test)
  • EnergyPlus ForwardTranslator Tests (in src/energyplus/Test)
  • If a new object or method, added a test in NREL/OpenStudio-resources: Add Link
  • If needed, added VersionTranslation rules for the objects (src/osversion/VersionTranslator.cpp)
  • Checked behavior in OpenStudioApplication, adjusted policies as needed (src/openstudio_lib/library/OpenStudioPolicy.xml)
  • Verified that C# bindings built fine on Windows, partial classes used as needed, etc.
  • All new and existing tests passes
  • If methods have been deprecated, update rest of code to use the new methods

Labels:

  • If change to an IDD file, add the label IDDChange
  • If breaking existing API, add the label APIChange
  • If deemed ready, add label Pull Request - Ready for CI so that CI builds your PR

Review Checklist

This will not be exhaustively relevant to every PR.

  • Perform a Code Review on GitHub
  • Code Style, strip trailing whitespace, etc.
  • All related changes have been implemented: model changes, model tests, FT changes, FT tests, VersionTranslation, OS App
  • Labeling is ok
  • If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
  • If feature, test running new feature, try creative ways to break it
  • CI status: all green or justified

@joseph-robertson joseph-robertson added the Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge. label Jan 22, 2020
@joseph-robertson joseph-robertson removed the Pull Request - Ready for CI This pull request if finalized and is ready for continuous integration verification prior to merge. label Feb 6, 2020
Copy link
Collaborator

@jmarrec jmarrec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on discussion on #3216 with screenshots and former comment from Dan, it seems that the fix is correct.

}

// glare
double glareAngle = -openstudio::radToDeg(primaryDaylightingControl->thetaRotationAroundYAxis());
double glareAngle = primaryDaylightingControl->phiRotationAroundZAxis();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The radToDeg shouldn't be there, great catch. Everything stored as deg. OpenStudio uses euler angles internally only

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the "-" was needed actually. @eringold has a file that is throwing in 3.2.1 but worked as 2.9.0, and I tracked it down to here.

   ** Severe  ** <root>[Daylighting:Controls][TZ_L6_BKS_Corridor/Toilets DaylightingControls][glare_calculation_azimuth_angle_of_view_direction_clockwise_from_zone_y_axis] - "-0.000000" - Expected number greater than or equal to 0.000000

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that the negative sign should stay. If E+ requires rotation angle to be positive you could also do a:

if (angle < 0){
  angle += 360;
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By "also" you mean "in addition" right?

If I follow correctly, openstudio's convention for phi is counterclockwise, which is the opposite of the convention for phi in E+ (clockwise)?

https://bigladdersoftware.com/epx/docs/9-5/input-output-reference/group-daylighting.html#field-glare-calculation-azimuth-angle-of-view-direction-clockwise-from-zone-y-axis

do you recall if it's documented somewhere (at least in code comments somewhere)?

Only thing I could find is this:

// rotate negative amount around the z axis, EnergyPlus defines rotation opposite to OpenStudio

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmarrec yes I meant in addition, if after applying the negative sign the result for E+ is still negative you can add 360. The angle mod 360 might also work, you could try it with a unit test. If you use the right hand rule, https://en.wikipedia.org/wiki/Right-hand_rule, with y pointing North and x pointing East, then a positive rotation around the z-axis (pointing up) is counter-clockwise when viewed from above. The E+ convention of positive rotation in the clockwise direction is backwards to most conventions.

@jmarrec
Copy link
Collaborator

jmarrec commented Feb 14, 2020

@joseph-robertson There's a minor merge conflict that I'll resolve.

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrong OS:Daylighting:Control rotation angle translated
3 participants