Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


cfdguru last won the day on June 29

cfdguru had the most liked content!

About cfdguru

  • Rank

Profile Information

  • Gender
    Not Telling
  • Are you University user?

Recent Profile Visitors

1615 profile views
  1. Hi @Nadzrin, The advancing front vs. Delaunay triangulation discussion actually refers to the surface meshing. AcuSolve doesn't have much of a preference either way when it comes to surface meshing. The runtime argument I made is in reference to the volume meshing (AcuConsole's octree vs HW-CFD's approach). In this case, the linear solver *should* perform better with the mesh from HW-CFD. Note that the performance won't be radically different between the two approaches, but according to our linear solver experts on the AcuSolve team, the more random mesh is beneficial. Would be an interesting test for someone to run. and report the results!
  2. Right. AcuConsole's mesher will create octree patterns in large open regions. That mesher works as follows: 1.) Create surface mesh using the delaunay triangulation approach 2.) Extrude boundary layers from the surface into the volume regions 3.) Build octree mesh in volume regions 4.) Connect the surface/boundary layer mesh to the octree regions using delaunay or advancing front technique. However, the question is what you feel is superior about the octree approach. The structured nature of an octree mesh is not beneficial to AcuSolve. The randomness of the nodal positions in the HW-CFD mesh tends to make the linear algebra less stiff and can actually lead to faster run times on meshes of similar node count. Additionally, the 2:1 size jumps that are present in the octree mesh can cause a stiff linear system in AcuSolve as well. Overall, you should see that the HW-CFD mesh performs better in the solver, and is also faster to generate due to the more effective use of mult-threading. I'd be interested to hear if your experience is not consistent with these expectations.
  3. Here's a bit more detail on why the two meshes are different. HW-CFD uses an advancing front meshing technique which will cause the mesh patterns to radially grow away from the edges. AcuConsole is using a Delaunay triangulation approach. So, you won't see the radial patterns in the mesh. Also, your original comment about volume meshing caught my attention. What is it about the AcuConsole volume mesh that you feel is superior to the HW-CFD volume mesh?
  4. This is actually a ParaView bug. The Ensight reader doesn't properly handle the displace coordinates option. There are a couple work arounds available. The easiest is to write the data out using CGNS format instead of Ensight. The other option would be to continue using Ensight format, but deactivate the "Mesh Motion" option in AcuOut (alternatively, you can just comment out the corresponding line in the .case file and not re-run the conversion). Then, you'll be able to displace the coordinates in ParaView manually by adding the mesh_displacement vector to the coordinates vector at each time step. This can be done using the Calculator filter by enabling the "Coordinate Results" option.
  5. This error generally means that you are using different versions of the code on the machine that generated the input and the machine on which you are trying to run the mesher. Make sure you are using consistent versions on both machines.
  6. To model an adiabatic wall, you need to set all mechanisms of heat transfer to zero. AcuSolve allows you to model various different heat transfer mechanisms on a given surface. So, let's discuss the two that you are referring to separately. The first mechanism is the heat transfer from the conduction and convection of the material adjacent to the wall that you are assigning boundary conditions to. To zero this mechanism of heat transfer, you need to set temperature_type=flux, and heat_flux = 0.0. The second mechanism of heat transfer that AcuSolve supports on the surface is heat flux to the surroundings that are not present in the model. Let's consider an insulated wall that is adjacent to a large room with a constant temperature. In this case, it may be desirable to model the convection of the wall to the surroundings. This can be accomplished by setting a convective heat flux coefficient and reference temperature. The default setting of convective_heat_coefficient=0.0 ensures that this mechanism of heat transfer is disabled. So in your case, if you want the wall to be truly adiabatic, you will need to set heat_flux=0.0, and convective_heat_coefficient=0.0. Note that when convective_heat_coefficient=0.0, the value specified for reference temperature is irrelevant.
  7. AcuSolve solves for the static pressure as a nodal value. So, what you are seeing in AcuFieldView is static pressure. You can easily compute dynamic pressure using the function calculator if you are interested in seeing contours of that.
  8. The error message indicates that you don't have the AcuSolve feature enabled in your license file. Have you checked the license file to see if that is indeed the case?
  9. This type of error generally appears due to some non-English characters being present in the AcuConsole database. Can you check for these in your surface/volume group names as well as the script that you wrote for the initial conditions?
  10. I think that explains it then. If the input file was written in V13.0, it won't run in V12.0. However, if it is written in V12.0, it will run in V13.0.
  11. What we need to see is the top of the .Log file where it tells what version of AcuPrep is running. It should look something like this: acuPrep: Date = Tue Nov 11 07:40:07 2014 acuPrep: Problem = channel acuPrep: Run = 1 acuPrep: Hostname = sacandaga acuPrep: Platform = Linux 3.11.10-21-desktop x86_64 acuPrep: Machine = linux64 acuPrep: Release = 13.0 acuPrep: Release date = Jun 6 2014 acuPrep: Number of subdomains = 1 acuPrep: Number of threads = 1 acuPrep: Working directory = ACUSIM.DIR acuPrep: ------------------------------------------------------------------ ...
  12. Could you upload your .Log file and .inp file? That will tell us exactly what is going on.
  13. This option should appear under the SIMPLE_BOUNDARY_CONDITION command. It looks like that is where you have it based on the error message. So, it may be that you are just using the wrong version of the code. The wall_function_heat_flux factor was introduced in V13.0, so make sure that is the version you are using.
  14. Density is available if you have DERIVED_QUANTITY _OUTPUT turned on in the AcuSolve input file.
  15. Hi Prashant, There are three steps required to perform a restart: 1.) Ensure that you have the RESTART_OUTPUT enabled in your first run. You will only be able to restart from the time steps for which this type of output is available on disk. 2.) Create a new input file that contains the RESTART{} command and the commands that you want to change. For example, you could create a file called myRestart.inp that contains the following: RESTART{} DENSITY_MODEL("Air"){ type = ideal_gas } RUN{} Note that you only need to issue the commands/parameters that you want to change in the restart file. 3.) Restart the simulation using the new input file: acuRun -inp myRestart.inp Check out the RESTART command in the AcuSolve Command Reference Manual for some more information. You can also search this forum. There have been some other posts regarding restart of simulations.
  • Create New...