Jump to content

acupro

Members
  • Content Count

    228
  • Joined

  • Last visited

  • Days Won

    12

Everything posted by acupro

  1. This ran through with both set to 400 steps as you last sent - using the latest (or close to) official releases of both codes - OptiStruct 2019.2 and AcuSolve 2019.1. The only thing I can suppose is that the older version 2017.2 you're using (likely on the OS side) had a bug in the stopping mechanism that has since been fixed. I've attached the OS .out file, along with the OS .h3d file. Are you able to update your installations to the latest release(s)? ailette-with-f.h3d ailette-with-f.out
  2. In AcuSolve, you've specified max_time_steps = 401, and final_time = 1E+1 (10.), with a time increment of 0.025. The AcuSolve job will stop at the specified final time of 10.0, or after 401 time steps - whichever comes first. Since 400 * 0.025 = 10.0, AcuSolve will stop after 400 time steps, rather than 401. It looks like you've specified the OptiStruct job to do 401 time steps with a time increment of 0.025. AcuSolve stops after 400 time steps, so the OptiStruct job errors out once the connection signal is lost. Try setting OptiStruct to do only 400 time steps, so it matches the stop time of AcuSolve.
  3. The OptiStruct .out file suggests to look at the .stat file. Does that give any ideas? Can you also upload the AcuSolve .Log file and the OptiStruct .fem file?
  4. That generally means the surfaces on the AcuSolve side and the OptiStruct side are not co-located. Make sure both models have the DC-FSI surfaces in the same location and are the same size/scale and shape. Just above the assertion you have in the Log file: Ave distance = 9.367829e-004; Max distance = 2.350710e-002. This means the maximum distance between the OptiStruct and AcuSolve surfaces is 2.350710e-02, larger than the Max allowed gap of 5.486660e-003. Check to ensure the surfaces are the same size, shape, and location in both models.
  5. In your AcuSolve input file (slab_dcfsi.inp) you have in Auto Solution Strategy: max_time_steps = 101. With a time increment of 0.01 sec, the final time is 1.01 sec. The tutorial instructions indicate to set final time to 3.0 - which matches with the final time in the OptiStruct .fem file. Thus in your case, AcuSolve is going to stop at 1.01 sec, while OptiStruct expects to go to 3.0 sec. AcuSolve stops, and causes OptiStruct to stop (error out). If you set max time steps set to 0 and set final time to 3.0 on the AcuSolve side, as in Section 1.3 of the tutorial instructions, you should be good to go.
  6. I'm not very good on the OptiStruct side, but apparently the OptiStruct side has finished and closed the connection to AcuSolve. I now see you've made changes to the tutorial model - or whichever model you're running. But whatever you've done on the OptiStruct side does not appear to be consistent with what you've done on the AcuSolve side.
  7. You probably need to remove the space after the commas - and maybe add a space after the = (but that is likely not necessary). Yes, you'll need to use a different value for each component. You can add all three, then just comment those you don't need at the particular time by placing # in front of that line. In the acuTrans command, you can specify which surface set you want to query. Example: acuTrans -osi -osis Fan1 -osiv moment See acuTrans -h for complete usage and/or review the Programs Reference Manual, acuTrans section
  8. If you issue the command: acuTrans -h you'll see one of the options is -mc for moment_center: acuTrans -h | grep center acuTrans: -mc <str> center about which moment is computed acuTrans: moment_center= 0,0,0 [default] If you're using Linux, you can add -mc 0.0,2.5,-2.3 to the acuTrans command directly. If you're using Windows, you'll need to add the option to your local Acusim.cnf file - as the Windows parser typically doesn't work well with the commas. (This also works for Linux if you don't want to type it as part of the acuTrans command.) For example, in the Acusim.cnf file add: moment_center = 0.0,2.5,-2.3
  9. You may be able to accomplish this using FVX scripting. You can get FVX information in the /fv/help/FV_ReferenceManual.pdf included in the installation. The attachment has an example from which to start, then maybe use the 'modify' command within a loop to change locations and perform the queries. (You may want to consult with your local Support team as well...) test.fvx
  10. I just ran through this tutorial, and it seems to work correctly as written. (I did notice that you had left Simple BC active for the Beam surface, where it should be inactive/off since it's handled by the External Code Surface command. In any case, it still ran when I did leave it active as you had it.) Is it possible you assigned the BCs to the wrong surface sets? Can you attach the slab_dcfsi.out and cci.txt files from your run? Which versions of AcuSolve/OptiStruct are you using? (I have HyperWorks CFD Solvers 2019.1 and HyperWorks Solver 2019.2.)
  11. Which physics phenomena are you trying to capture with the simulation? Can you add the .inp file and .Log file?
  12. You should probably post that question to the OptiStruct forum - rather than this AcuSolve forum.
  13. AcuConsole doesn't support the mixed-element topology the same way that HyperMesh does. If you build the mesh as all-tets in HyperMesh (boundary layers, everything all tets) then you'll see the same groupings in AcuConsole.
  14. Most likely there is some problem with the problem setup, with the Assertion at the start, plus the BC Warnings in the Log file. Best to contact your local support office.
  15. I'm wondering if there's some difference in the keyboard/language of your OS. The original error is: Invalid command line option <ûto> where if it was related to the problem name not being specified, it would be something like: "Undefined problem". Is it possible you have two different characters that look like the - on your keyboard?
  16. When you launch the AcuSolve simulation from AcuConsole a file called Acusim.cnf will be written. This contains at least the problem name, along with other settings. Provided you keep working in that same directory where the Acusim.cnf file is written, you won't need to specify the problem name on the command line. If you move things around to other directories, etc, then you either need to have a local Acusim.cnf file with the problem name in it, or include the problem name on the command line.
  17. What kind of simulation are you running? What are the physics you are trying to solve? What is the maximum expected Mach number? Are you running this transient or steady-state? (If transient, you may want to try increasing the max-stagger-iterations and/or decrease the time increment.) Have you looked at the effect of refining the mesh? Have you looked at the effect of different turbulence models? These are the kinds of questions to be studied when determining if the approach to a simulation is adequate/correct - to qualify the simulation. Though it does appear the quantities you show have basically stabilized, they could also stabilize to an incorrect value if the modeling approach is not correct/adequate. This may be a good case for working directly with your Altair support team.
  18. I would point you to the AcuSolve Training Manual that is included as part of the Help documentation for AcuSolve. AcuSolve Training Manual > Theoretical Background > Turbulence > Modelling of Turbulence > Near-Wall Modelling. This has a good discussion of the turbulent boundary layer, including Y+. Note that in AcuSolve, the 'y' value used in the Y+ computation is the location of the first mesh node away from the wall, not the center of the first cell.
  19. 1. That warning indicates there are fluid volume elements on both sides of the indicated surface. You should not have volume mesh inside the wheel itself. 2. I also see this in the Log file: acuSolve: *** y+ is negative number You may have other issues with the setup as well. Can you post the .inp file generated for the run? (Not the mesh itself, just the .inp.) You may also be better off contacting the Altair support team in India.
  20. If I understand correctly, you want to show streamlines on a plane, where the streamlines neglect the out-of-plane velocity component. Is that correct? If that is not correct - what do you mean by '2D Streamlines'? Can you share an image comparing 2D and 3D streamlines for the same case? If my assumption is correct - that you want to neglect the out-of-plane velocity component, try the following. This assumes you want a Z-normal plane, and the Z-velocity component is neglected. 1. You need to create a vector using only the X- and Y-velocity components. In the Function Specification, use this: UnitX*"x-velocity" + UnitY*"y-velocity" then give it the name you desire. 2. When you create your streamlines on a Z-normal plane (Z - Coordinate Surface), use that vector function just created for 'Vector Function' instead of the default 'Velocity'. I'm not 100% positive on this - but does that accomplish what you want?
  21. My guess would be that static pressure would be typical, as that is simpler to measure, and doesn't obstruct the flow. Simply drill a hole in the side of the inlet and outlet pipes and put a tube there - flush to the inner/wetted surface. A total pressure measurement requires a pitot probe - where you install a device that protrudes into the flow and bends such that it points directly into the oncoming flow. I assume there's no harm in reporting both, but I would guess static pressure rise is typically reported.
  22. The pre-built mapping/transfer tools are only available for shell and/or solid elements. You may try contacting your local Altair support team to see if there are scripts that might work with beams.
  23. The equation given in the tutorial compares static pressure. If you want to compare total pressure, then your expression would be correct. It depends on what you want to compare - static or total.
  24. Based on my quick look at the database, you do not have the interface surface attached to the Rotor volume - only that for the Fixed/main volume. Right-click 'Air-rotor' under Volumes and select Mesh Op. > Find Missing Surfaces. This will generate the other set of surfaces, attached to the Rotor Volume. It appears you already have two sets of nodes there, but the surface definition was missing. This new surface set should have the same treatment as 'interface' > deactivate Simple BC, and activate Interface Surface with 0 for gap and gap_factor. If you know or can estimate the angular velocity, it's simpler to use rotation mesh motion rather than rigid body. It's difficult to estimate the resistance to rotation due to the gearbox, etc, so the angular velocity / rotation from Rigid Body motion is probably going to be higher than the actual would be.
  25. Turning off multi-field option in Auto Solution Strategy is not enough. (In fact, it shouldn't even appear there...) It needs to be turned off in Problem Description (becomes EQUATION command in the .inp). In Problem Description, Multiphase equation should be set to 'None'.
×
×
  • Create New...