Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

still existing UserParm Update issue with 3.25.0 #201

Open
RY3A1R opened this issue Sep 13, 2021 · 2 comments
Open

still existing UserParm Update issue with 3.25.0 #201

RY3A1R opened this issue Sep 13, 2021 · 2 comments
Assignees

Comments

@RY3A1R
Copy link

RY3A1R commented Sep 13, 2021

Hi guys,

thanks for fixing a lot of the update bugs.
I tried reproducing update bugs and found that one mentioned earlier (in #189) still exists:

  1. open OpenVSP
  2. Go to File -> open -> select the provided file
  3. Go to Model -> User Parms -> Adjust -> AR_ratio
  4. Set the value to 5 by using the text field, do not touch the slider or select anything
    and pressing enter -> The geometry updates somewhat
    The wing tip moves forward slightly
  5. Set the value to 5.000001 and press enter -> Rear Wing Aspect Ratio changes, Tip moves aft
  6. Set the value to 5 and press enter -> Tip moves to correct location
  7. Set the value to 5.000001 and press enter -> nothing changes visibly (as we would expect)
  8. The fore-aft wing tip movement cannot be fixed by selecting the rear Wing in the geom browser.

The wing tip fore-aft movement issue seems to be unrelated to the Aspect Ratio change issue, as it does not only occur after file load. Each later change in AR_ratio requires 2 Updates of the parameter to work correctly. (Updates only occuring when the paramter actually changes, so something like 1.0 -> 1.000001 is required.
My first guess was some sort of iteration going on inside the Adv Link, with out link code relying on one of its outputs to work correctly. However, I can't find any issues there.

Can the Aspect Ratio setting or the fore-aft movement issue stem from the fact that we set a parameter directly that is not a fundamental parameter of the wing, but one that is calculated based on the basic wing parameters?

Cheers,
Julius

Originally posted by @RY3A1R in #189 (comment)
OpenVSP_Bug_Uservars.vsp3.txt

@ramcdona
Copy link
Contributor

Can you duplicate this issue using something other than a Wing and somewhat larger perturbations than .000001 ?

I see three potential issues...

The wing has a somewhat more complex update path than other components because of the way the wing sections combine to form the total -- and because one section's tip is the next section's root. These factors have been known to cause some problems with wing updating from things like advanced links and scripts.

Next, there is a tolerance on Parm changes that OpenVSP ignores. If you make too small a change, OpenVSP will not trigger an update.

Finally, there are potential issues related to User Parms and Advanced links.

So, if you can try some more basic tests, we can hopefully isolate which factor (or combination of factors) is causing the problems you are seeing.

@justingravett justingravett self-assigned this Sep 16, 2021
@justingravett
Copy link

I'm not entirely sure if this is a bug or just a limitation of Advanced Links. You have two Parms that are both inputs and output Advanced Links: input "rw_x" -> output "wing_rear_x" & input "rw_z" to output "rear_wing_z". When the output Parm "wing_rear_x" is set in the Advanced Link script, OpenVSP updates the input Parm "rw_x" before completing the script. This causes the Geom to fail to update in the GUI until another update is triggered. If you can, it's best to avoid using the same Parm as an input and output in Advanced Links.

If you do need to do so, instead use the input Parm before it's associated output is set in the script. Everything should update correctly if you reorganize your script like this:

                        joint_ref_u_attach = 1./3. + 1./3.*span_ratio;
						
			double dx = x_jr - rw_x;
			double dy = y_jr - rw_y;
			double dz = z_jr - rw_z;

			wing_rear_x = wing_front_x + 0.25*wing_front_c + h_stagger*fw_b - 0.25*wing_rear_c; 
			wing_rear_z = wing_front_z + v_stagger*fw_b;
			
			const float pi = 3.141592f;
			
			double dy_sw = sqrt(dy**2+dz**2);
			
			rw_sw_loc = 0.0;
			
			rw_AR = AR_ratio*fw_AR;
			
			rw_dihedral = dz/abs(dz) * atan(abs(dz)/abs(dy))/pi*180;
			rw_sweep = dx/abs(dx) * atan(abs(dx)/abs(dy_sw))/pi*180;
			rw_span = sqrt(dy**2+dz**2);
			
			wf_l = 2*rw_c_tip;
			wf_xRel = -2*rw_c_tip;
			
			fw_taper = taper_fw;
			rw_taper = taper_rw;
			
			fw_b_tess = b_tess;
			rw_b_tess = b_tess;
			
			fw_c_tess = c_tess;
			rw_c_tess = c_tess;
			
			fw_tip_cluster = tip_cluster;
			rw_tip_cluster = tip_cluster;
			
			fw_LE_cluster = LE_TE_cluster;
			fw_TE_cluster = LE_TE_cluster;
			
			rw_LE_cluster = LE_TE_cluster;
			rw_TE_cluster = LE_TE_cluster;
			
			Sref = fw_area+rw_area;
			bref = fw_b;
			cref = wing_front_c+wing_rear_c;
			
			inc_wingRear_out = inc_wingRear;
			inc_wingFront_out = inc_wingFront;
			tw_wf_out = tw_wf;
			tw_wr_out = tw_wr;
			
			sec1_tess_x = sec1_x*fus_tess_x;
			sec2_tess_x = (sec2_x-sec1_x)*fus_tess_x;
			sec3_tess_x = (sec3_x-sec2_x)*fus_tess_x;
			sec4_tess_x = (sec4_x-sec3_x)*fus_tess_x;
			
			fus_tess_y_out = fus_tess_y_in;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants