Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by yao

  1. For example, I want to disable meshing of solid volumes - and mesh only the fluid volumes. In AcuConsole V1.7f and later - under the Volume Mesh Attributes, set the Mesh size type to 'NoMesh'.
  2. The AcuSolve tool (shell script) 'reform' reformats existing files - and can be used to extract nodes from a surface or volume. It is located in the /tools/ directory of Linux/Unix installations. Extract nodes from a surface (.ebc) file: reform -3,100,1 surface1.ebc | sort -nu > surface1.nbc Extract nodes from a volume (.cnn) file: reform -2,100,1 volume1.cnn | sort -nu > volume1.nbc
  3. Specify the Simple_Boundary_Condition with 'temperature_type = flux' with the desired values. Add a Nodal_Boundary_Condition on the surface with the desired temperature - but add 'active_type = user_function'. Within the user function, the return value should be '1' when the temperature condition is desired and '0' when the flux condition is desired. The attached example has an AcuConsole database and the sample UDF. First, compile the UDF via acuMakeLib or acuMakeDll. Start acuConsole, open the database, and create the mesh (meshing parameters are assigned). Then run the problem. The duration of the problem is 12 seconds. Time 0-2 and 6-8 have fixed temperature and 2-6 and 8-12 have the flux condition.
  4. The 'Center' array defines any point (x, y, z) that lies on the axis of rotation (using the assumption that the axis is infinite in length). The 'Angular Velocity' array defines the rotation vector in radians per second - using the right-hand rule for the 'sense' of rotation.
  5. To perform a restart in AcuSolve, there are two conditions that must be satisfied: 1.) The RESTART_OUTPUT command must be included in the simulation that you want to restart from. This command writes all data necessary to restart a simulation to disk at the specified intervals. 2.) The RESTART command must be included in the input file of the run that you are restarting. The only changes that are made to the simulation once the restart is performed are the commands that appear after the RESTART{} commmand in the input file. In the attached example, the flow was first solved using a steady state simulation. To restart the simulation, and solve only for turbulence (i.e. using the previous flow solution), simply execute acuRun. The input file contains all of the commands necessary to restart the run. Please see the AcuSolve Commands Reference Manual for more information about the RESTART and RESTART_OUTPUT commands. AcuSolve’s reference manuals can now be accessed through AcuConsole’s Help menu, To see the available manuals, select Help–>AcuSolve Help Home. This will bring up the searchable html version of the manuals.
  6. If I want to use the solution from a previous run as my initial condition for a restart, do I need to remove the NODAL_INITIAL_CONDITION command from my input file when restarting? The RESTART command simply reads the input data from a previous run (the last run by default unless a different run is specified). Any command appearing after the RESTART command will be processed and overwrite the settings from the previous run. NODAL_INITIAL_CONDITION, however, does have special behavior....when the RESTART command is processed, it automatically uses the data from the previous run. So, here are some scenarios to illustrate RESTART and NODAL_INITIAL_CONDITION. Consider the following input files for the restart run: This will pull the previous run's data for the initial conditions: RESTART {} RUN{} This will also pull the previous run's data for the initial conditions because the RESTART comes after the NODAL_INITIAL_CONDITION command (i.e. the restart data overwrites the NODAL_INITIAL_CONDITION data): NODAL_INITIAL_CONDITION(velocity){ variable = velocity values = {1,0,0} } RESTART {} RUN{} This will OVERWRITE the previous run's data for the initial conditions with 1,0,0 because NODAL_INITIAL_CONDITION comes after RESTART: RESTART{} NODAL_INITIAL_CONDITION(velocity){ variable = velocity values = {1,0,0} } RUN{}
  7. The work flow pattern of a typical AcuSolve run involves running a preprocessor (acuPrep - a single processor executable) that reads the user input and prepares data for parallel execution. This preprocessor writes files back to an NFS mounted (or network shared) disk for the solver to read when it is launched. Once the parallel solver processes are launched, each processor (or core) of the solver reads its part of the data and starts execution. As the simulation progresses, each solver process writes its own files back to the NFS mounted disk. These files are written at the end of each time step. The user determines the frequency at which these files are written, as well as how many files are written based on the output settings that are specified in the input file. One file is written for each solver process, each time step, and each output type. This can result in thousands of files being created in the output directory. To minimize the file count, acuSolve offers a command line option (-csout) that merges all files of a single output type at each time step (i.e. reduces the number of files at a given timestep by a factor of nProcessors). AcuSolve writes no temporary files (scratch files) during execution, and does not utilize the local disk when running in parallel. At the end of each solver run, AcuSolve prints a summary of how much CPU and elapsed time is spent writing files to disk. This provides a convenient method for users to profile the solver runs and determine how efficient their file system is. For common output frequency settings, the total I/O time for a parallel run is typically 5% or less of the total run time. Output speed is highly dependent on the system hardware and type of simulations that are run. Users are encouraged to evaluate the I/O speed of their systems using simulations that are typical of their business.
  8. If you have a compiler on your system, make sure the /bin/ directory of the AcuSolve installation is included in the PATH environment variable. Then from the compiler command prompt - and in the directory where the UDF is located - issue acuMakeDll. For example, on a WIN64 machine with Visual Studio 2005 installed, place the following in the C:\Program Files (x86)\Microsoft Visual Studio 8\VC\bin\amd64\vcvarsamd64.bat file. These lines can be copied from the \bin\Acusim.bat file located in the AcuSolve installation. set ACUSIM_HOME=C:\Acusim\ set ACUSIM_VERSION=V1.8b set ACUSIM_MACHINE=WIN64 set ACUSIM_ROOT=%ACUSIM_HOME%\%ACUSIM_MACHINE%\%ACUSIM_VERSION% set ACUSIM_SYSTEM_CNF=%ACUSIM_ROOT%\script\Acusim.cnf set ACUSIM_CNF_FILES=.\Acusim.cnf:~\Acusim.cnf:%ACUSIM_SYSTEM_CNF% set PATH=%ACUSIM_ROOT%\base\lib\site-packages;%PATH% set PATH=%ACUSIM_ROOT%\base\DLLs;%PATH% set PATH=%ACUSIM_ROOT%\base\bin;%PATH% set PATH=%ACUSIM_ROOT%\bin;%PATH% There is no compiler included with the AcuSolve distribution, so you will need to obtain your own compiler. It needs to be a 32-bit compiler for 32-bit installations, and a 64-bit compiler for 64-bit installations.
  9. The FAN_COMPONENT simply adds body forces to the flow field to model the effect of the fan. There are two types of fan that are supported....an axial fan, and a radial fan. An axial fan is similar to the cooling fan in front of a car radiator. The flow enters along the axis of rotation, and the fan imparts a pressure rise to the flow. A radial fan (also known as a centrifugal fan) is typically enclosed in a housing, and the flow enters along the axis of rotation but exits perpendicular to the axis of rotation. An example of this would be the blower in the heating system of a car or a turbocharger. When defining a FAN_COMPONENT, a body force is added to all of the volume elements in the parent element set of the surface. So, separate element set should be used to model the fan. The fan_thickness should correspond to the length of the element set. The magnitude of the body force is given by the equations shown in the Command Reference Manual. The axial, radial, and tangential pressure drops can all be modeled. The attached example illustrates the steps necessary to convert a P-Q into the appropriate input data for FAN_COMPONENT when modeling a radial fan with an axial coefficient of type=bilinear_curve_fit. This example utilizes an axial coefficient that is constant with radius, but varies with flow rate through the fan.
  10. Make sure you have files installed for East Asian Languages. On XP, go to Control Panel and select "Regions and Language Options". Then, select the Languages tab. Check the box next to Install files for East Asian languages option. Windows will prompt to restart. Restart XP and the Japanese characters should be displayed.
  11. Heat Transfer into the fluid domain is positive - when referring to OSI Heat Flux or ORI Heat Flux. However, heat transfer into the domain for OSI Convective Temperature Flux is negative - because of the U dot N term in the integral. (See the chart in the acuTrans section of the Programs Reference Manual.) The total heat flux across a surface is the sum of OSI Convective Temperature Flux, OSI Heat Flux, radiation surface heat flux, solar radiation surface heat flux. In order to perform an energy balance across a control volume, all of these components must be summed. It is not possible to break out conduction and convection portions of the heat flux. (Note that Convective Temperature Flux is not the convection heat transfer at the wall - in fact the Convective Temperature Flux should be nearly zero at the wall - because it is due to the flow - and there should be zero flow at the wall.) When you sum the various types of heat flux for all of the bounding surfaces, the sum should be nearly zero - depending on convergence.
  12. Internal surfaces within AcuSolve have two sides to them that contain different element numbers. However, these elements contains identical nodes if the surface has not been split. For the case of conjugate heat transfer, the appropriate boundary condition to apply is a SIMPLE_BOUNDARY_CONDITION, type=wall on the fluid side of the surface. Note that by default, the type=wall sets heat_flux=0. However, in the case of an internal surface shared by a fluid and solid, heat is transferred directly between the elements due to the fact that they are connected by shared nodes. Therefore, the heat_flux=0 condition does not prevent heat transfer. A non-zero heat flux can be specified to model an addition of heat due to some external source (such as an embedded heating wire in a rear window defroster).
  13. In the AcuSolve ..Log file, the first line of the time step indicates the Time Increment and the Time at the start of the time step, before any calculation has been done for that time step. Thus, at the start of a new calculation, the starting Time value will be 0.0. Once the calculation has started for the time step, the time advances, and any 'Time' value returned by a UDF or used within the calculation will be the advanced time for that time step.
  14. AcuSolve performs profiling of each run to determine where the majority of the CPU/elapsed time is spent during the simulation. The results of this profiling are printed to the .Log file at the conclusion of each run, and can be reviewed by users to assess the performance of the code on their computing system. The results from a representative .Log file will be reviewed to explain the output. Following the completion of the last time step, AcuSolve will print information regarding the input/output time, message passing time (for distributed memory parallel simulations), interface search time (if non-conformal interfaces are present), time associated with the solution of each stagger, and total time to complete the simulation. The memory usage of the simulation is also reported in the log file. For distributed memory parallel simulations, the average and maximum CPU Times and Memory usage are printed to indicate if reasonable load balancing was achieved by the domain decomposition. The following output shows a summary at the end of a typical distributed memory parallel AcuSolve simulation that solved for flow, turbulence, temperature, and enclosure radiation. No INTERFACE_SURFACES were defined for the simulation. acuSolve-hpmpi: ----------------------- End Time Step ----------------------- acuSolve-hpmpi: Input CPU/Elapse time= 5.873000e+01 2.292031e+02 Sec acuSolve-hpmpi: Output CPU/Elapse time= 1.872900e+02 2.104051e+02 Sec acuSolve-hpmpi: Exchange CPU/Elapse time= 1.425620e+03 2.088389e+03 Sec acuSolve-hpmpi: Intf.search CPU/Elapse time= 0.000000e+00 0.000000e+00 Sec acuSolve-hpmpi: Flow stagger "flow": acuSolve-hpmpi: No of res/lhs formations = 100 100 acuSolve-hpmpi: Elem.Form CPU/Elapse time= 4.605900e+02 6.453795e+02 Sec acuSolve-hpmpi: Solution CPU/Elapse time= 4.722590e+03 4.884696e+03 Sec acuSolve-hpmpi: Turbulence stagger "turbulence": acuSolve-hpmpi: No of res/lhs formations = 100 100 acuSolve-hpmpi: Elem.Form CPU/Elapse time= 2.556100e+02 2.722640e+02 Sec acuSolve-hpmpi: Solution CPU/Elapse time= 3.474900e+02 3.841555e+02 Sec acuSolve-hpmpi: Temperature stagger "temperature": acuSolve-hpmpi: No of res/lhs formations = 100 100 acuSolve-hpmpi: Elem.Form CPU/Elapse time= 2.524900e+02 2.791516e+02 Sec acuSolve-hpmpi: Solution CPU/Elapse time= 3.178700e+03 3.378577e+03 Sec acuSolve-hpmpi: Radiation stagger "radiation": acuSolve-hpmpi: No of res/lhs formations = 100 100 acuSolve-hpmpi: Elem.Form CPU/Elapse time= 1.380000e+00 9.432842e+00 Sec acuSolve-hpmpi: Solution CPU/Elapse time= 8.090000e+00 2.437304e+01 Sec acuSolve-hpmpi: Total CPU/Elapse time = 9.569710e+03 1.048043e+04 Sec acuSolve-hpmpi: Total Memory Usage = 1.474883e+02 Mbytes acuSolve-hpmpi: Ave Processor CPU time = 8.891656e+03 Sec acuSolve-hpmpi: Max Processor CPU time = 1.028060e+04 Sec acuSolve-hpmpi: Ave Processor Memory Usage = 1.477044e+02 Mbytes acuSolve-hpmpi: Max Processor Memory Usage = 1.579727e+02 Mbytes acuRun: -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- The Input and Output times report the amount of time that AcuSolve spent reading and writing files to disk. The differences between the input and output CPU/Elapsed times are caused by file system delays. When running AcuSolve in parallel, many processes may be trying to read/write to the same NFS mounted disk. When this happens, delays can occur, forcing AcuSolve to wait for file I/O. This causes the Elapsed time to increase while no CPU time is being used. Differences in CPU/Elapsed time can also be caused by processes competing for run time on an overloaded machine. The Exchange time indicates how much time AcuSolve spent passing messages between processes. For most simulations, the value of the Exchange time is 20% or less of the total time required to complete the simulation. When there is a significant difference between the CPU/Elapsed time, the implication is that there is a message passing bottle neck somewhere. This can be caused by a poorly performing network, or a switch that is unable to handle all of the traffic that it is receiving. The Intf. Search time reports the amount of time that AcuSolve spends searching for matching faces for nonconformal interfaces (i.e. INTERFACE_SURFACE command). When a simulation containing INTERFACE_SURFACES is performed in a distributed memory parallel configuration, the search algorithm must communicate with other processes to find matching faces. Because of this, a significant amount of message passing must occur. When significant differences in CPU/Elapsed time are seen for this metric, it is typically due to delays in exchanging messages across the network/switch while searching for interface matches. For each stagger that is solved, AcuSolve reports a total of 3 metrics: No. of res/lhs formations, Elem. Form time, and Solution time. The No. of res/lhs formations is a tally of how many times the residual of the equation was computed, as well as how many times the left-hand-side matrix was formed. By default, these values should match each other, and reflect the total number of times the equation was solved. It should be noted that the LHS matrix formation frequency can be adjusted, causing these two values to be different. However, this is an advanced option, and is rarely changed. The Elem. Form time refers to the amount of time required to form the LHS matrix and loop over all of the elements to compute the residual of the equations. Any significant deviations between the CPU/Elapsed time for this metric are primarily due to delays in exchanging messages across the network/switch or competing processes on a machine that is overloaded. The Solution time that is reported for each stagger refers to the amount of time required by the linear solver routines to converge to the desired tolerance. The total elapsed time of the simulation is typically dominated by the solution time for the various staggers. Any significant deviations between the CPU/Elapsed time for this metric are primarily due to delays in exchanging messages across the network/switch or competing processes on a machine that is overloaded. The Total CPU/Elapsed time represents the accounting of all steps that AcuSolve performs in completing the simulation. Any significant deviations between the CPU/Elapsed time for this metric are primarily due to delays in exchanging messages across the network/switch or competing processes on a machine that is overloaded. One other possible cause of large differences is running the machine out of memory, forcing it to write data to swap files. Note that simply summing all other timing metrics in the summary of the log file will not yield the same value as the total CPU/Elapsed time. There are additional operations in the solver that are not profiled due to their insignificance.
  15. For a given element (except for the fifth node of a pyramid) each node is connected to three other nodes via three connected edges. Assume R1, R2, and R3 are the vectors for the three connected edges. For a positive Jacobian: ( R1 × R2 ) · R3 > 0 This test is done for every node of every element - so a mesh with 10K tetrahedral elements would yield 40K Jacobian tests.
  16. During the processing stage, acuPrep determines whether or not 'surfaces' from Simple BC or Element BC commands are boundaries or internal to the parent element set. If a surface element (tri or quad) has a volume element on only one side - or volume elements from different sets on both sides - it is considered to be a boundary. If a surface element has a volume element on both sides, and those volume elements are in the same element set - it is considered to be internal. If there are surfaces in the geometry between volumes in the same element set, these surfaces should not have Boundary Conditions defined. If there truly is an internal 'wall' (such as a baffle) within a given volume, the mesh surfaces should be split to yield two sets of nodes and two sets of surface elements.
  17. The first time you run this program, it will go through an installation process. Please click ok on dialogs that appear when you first run acuReport. In the process, if it ask for any package installation of Latex please download the updated miktex.zip from the public area on our client vault. Unzip the compressed file and replace the miktex folder in /base/bin of AcuSolve installation. More Details: acuReport is a post processing tool that extracts data from AcuConsole database, AcuSolve output and any other user data. One has to create a simple python script to access data from different sources.AcuReport converts the python script into a latex document that could then be converted into pdf, html or an rtf document. Depending on the features of Latex that one uses, latex distribution could be as big as 2GB. Both on windows and linux we are including some of the standard packages in Latex that are used most of the time. If the users wants to go beyond these standard packages, they can download and add to the existing latex/miktex distribution. On windows, we use miktex. In V1.8 we did not include all the standard miktex packages required by acuReport. Miktex downloads packages as needed and hence some of the users might encounter problems while running acuReport, because they don't have the permissions to download and install the package on their machine. For now, please download the updated miktex package in the public area on our client vault. This will also be part of V1.8a distribution. On Win64, there is a known issue that we are trying to resolve. The plotting package does not render the plots correctly. This is an issue with matplotlib package that we are trying to fix it. Finally, acuReport is still in preview mode. Please feel free to provide your feedback so that we can make it useful for your applications.
  18. By default, the nodes and element connectivity are absent from the OP2 file. This is done by design. FEMAP writes a parameter "PARAM OGEOM NO". This means do not write geometry to the op2 file. This is done because the pre-processor already has the geometry loaded and hence it needs only the results from the file. Workaround: Simply disable this parameter using the deck editor in FEMAP or remove this parameter by editing the deck outside of FEMAP
  19. The example AcuConsole database included here includes the heat exchanger component from the Command Reference Manual. To see the setup, click 'All' from the left-hand column, then expand the 'HX_Inlet' surface and expand 'Advanced Options' to see that Heat Exchanger Component is active. Double-click to see the entries. Run the example solution to view the results.
  20. Yes, AcuConsole does support a generic format for importing modal results. It is called AcuSolve Modal Response (AMR) format. Here is how it works: 1.) A single XML file contains the eigen values and references to other files containing the nodal coordinates, element connectivity, and eigenvectors for each mode. 2.) This XML file is what is read by AcuConsole. To accomplish this, go to the eigenMode Manager, select Open, then choose ACUSIM Modal Response from the File type filter drop down menu. You can now read in the XML file (with a .amr extension). Attached is an example showing the AMR format. Start by looking at the file named modalResponse.amr. This is the XML file. The format of that should be pretty obvious, but here is an explanation of it: coordinates Tag: Reads a file containing the coordinates of the structural model. This file contains nodeId xCrd yCrd zCrd element_set Tag: Reads the element connectivity of the structural model and specifies whether it is a 2-d or 3-d mesh. The format of the file is as follows: elementId node1 node2 node3 node4 ....... mode Tag: Specifies the eigenvalue for each mode, the mode index, and references the file containing the eigenvector. The format of the eigenvector files is: nodeId xEigenVector yEigenVector zEigenVector. Make sure that the eigenvalues are mass normalized when you import them into AcuConsole.
  21. This behavior has been seen when some of the Windows System directories have been removed from the PATH (or Path) environment variable. Make sure the following are in your System level Path variable: %SystemRoot% %SystemRoot%\system32 %SystemRoot%\System32\Wbem %SYSTEMROOT%\System32\WindowsPowerShell\v1.0
  22. The script acuFixPath in the \bin\ directory will modify .bat files to update the installation area. Use 'acuFixPath -h' for usage of the command. For example, by default, the installation may go to C:\Acusim\WIN\V1.8\... and you want to change it to D:\Home\Acusim2\WIN\V1.8. First you would copy the installation directories and contents appropriately. Then go into the D:\Home\Acusim2\WIN\V1.8\bin directory (just copied/created) and issue: acuFixPath -home D:\Home\Acusim2 -machine WIN -version V1.8 The ..\bin\*.bat files should be updated to match the indicated locations. Note that you may need to update some of the .bat files manually (acuC2A.bat, acuFv.bat, acuGetMachine.bat) and settings in the \script\Acusim.cnf file. You may also wish to add/modify environment variables at the User or System level.
  23. When trying to execute multiple acuRun jobs consecutively in a batch file, it is necessary to launch the processes using the "call" command. Without issuing the call command, the cmd interpreter exits the main batch file after the first instance of acuRun completes. This is because acuRun is also launched through a batch file, and Windows receives the exit signal upon its completion. The following commands represent an example of a batch file that will circumvent this issue by using the call command: cd D:\test\pipe1 call acuRun -pb pipe1 -np 2 cd D:\test\pipe2 call acuRun -pb pipe2 -np 2
  24. This error sometimes occurs on Windows Vista 64, and is related to the UAC (User Access Control) feature in Windows Vista. Even if the user has administrator privileges, some applications (acuLmd, for example) may be blocked. Go to the directory where the application executable resides, right-click on its icon, and select "Run as an administrator."
  25. AcuSolve's porosity model provides a great deal of flexibility to end users to model many types of porous media including anisotropic resistance. The attached document includes details and examples of how to set up porosity models for specific applications. The document also includes details on how to use the curve fitting program, acuPorous, that is shipped with AcuSolve
  • Create New...