The On Ramp/Level 1/Partition - Revision history

Jrwrigh: /* Chef */ Link to Chef wiki page

2022-09-18T18:39:27Z

‎Chef: Link to Chef wiki page

Jrwrigh: Jrwrigh moved page Level 1 Partition to The On Ramp/Level 1/Partition: Move to a subpage organization

2022-09-18T18:38:32Z

Jrwrigh moved page Level 1 Partition to The On Ramp/Level 1/Partition: Move to a subpage organization

Jeffhadley: /* Creating the serial case via Viz nodes */

2021-06-15T15:44:30Z

‎Creating the serial case via Viz nodes

Conrad54418: /* A few helpful video tutorials */

2021-06-11T18:31:14Z

‎A few helpful video tutorials

Conrad54418: /* A few helpful video tutorials */

2021-06-11T18:14:47Z

‎A few helpful video tutorials

Conrad54418: /* A few helpful video tutorials */

2021-06-11T18:14:33Z

‎A few helpful video tutorials

Conrad54418: /* A few helpful video tutorials */

2021-06-11T18:13:53Z

‎A few helpful video tutorials

Conrad54418: /* A few helpful video tutorials */

2021-06-11T18:13:21Z

‎A few helpful video tutorials

Conrad54418 at 18:11, 11 June 2021

2021-06-11T18:11:21Z

Conrad54418: /* Further Partitioning to N processes */

2021-06-09T18:00:34Z

‎Further Partitioning to N processes

@@ Line 1: / Line 1: @@
 == Chef==
-Chef is an open source SCOREC tool that is this group's primary tool to partition a problem domain to many subdomains. This is done to allow any array of compute nodes to each focus on solving the problem in parallel. That is, to divide the problem domain into subdomains to give to different computational workers. When we perform this step, all that is needed for inputs are the, 1) SCOREC mesh constructed from the output of the conversion and meshing steps, and 2) the number of parts (subdomains) to divide the problem up into. A generic workflow for this step is described below and is a good place to start when completing the workflow for the first time. As your studies continue, many aspects of the layout and modifiers will not be consistent with this On Ramp documentation.
+[[Chef]] is an open source SCOREC tool that is this group's primary tool to partition a problem domain to many subdomains. This is done to allow any array of compute nodes to each focus on solving the problem in parallel. That is, to divide the problem domain into subdomains to give to different computational workers. When we perform this step, all that is needed for inputs are the, 1) SCOREC mesh constructed from the output of the conversion and meshing steps, and 2) the number of parts (subdomains) to divide the problem up into. A generic workflow for this step is described below and is a good place to start when completing the workflow for the first time. As your studies continue, many aspects of the layout and modifiers will not be consistent with this On Ramp documentation.
 === Creating the serial case via Viz nodes===
 Create a <code>1-1-Chef</code> subdirectory inside the <code>PrepAndRun</code> folder. Enter the new folder and copy over the files <code>adapt.inp</code> and <code>runChef.sh</code> from the <code>/projects/tutorials/OnRamp</code> folder. To learn more about the <code>adapt.inp</code> file, enter the command:

@@ Line 6: / Line 6: @@
   more adapt.inp
-Pay particular attention to the splitFactor, attributeFileName, modelFileName, meshFileName bz2, and outMeshFileName bz2 specifications. These are often the first nobs that the new user learns to control. When it comes to first creating "checkpoint" files that are needed for the PHASTA executable. splitFactor will tell the Chef executable how many partitions each incoming part needs to be partitioned by. Immediately after the conversion step we want this to be set to 1 because we desire a single "checkpoint" file. attributeFileName will tell Chef where the file that contains the attributes of each geometry entity (region, face, line, and vertex info) is. Likewise, the modelFileName will tell Chef where the file that contains the geometry entity information is. The  meshFileName bz2 and  outMeshFileName bz2 specifications determine the directory where Chef will look to gather the SCOREC mesh and where to put the partitioned SCOREC mesh.
+Pay particular attention to the splitFactor, attributeFileName, modelFileName, meshFileName bz2, and outMeshFileName bz2 specifications. These are often the first nobs that the new user learns to control. When it comes to first creating "checkpoint" files that are needed for the PHASTA executable. splitFactor will tell the Chef executable how many partitions each incoming part needs to be partitioned by. Immediately after the conversion step we want this to be set to 1 because we desire a single "checkpoint" file. attributeFileName will tell Chef where the file that contains the attributes of each geometry entity (region, face, line, and vertex info) is. Likewise, the modelFileName will tell Chef where the file that contains the geometry entity information is. The  meshFileName bz2 and  outMeshFileName bz2 specifications determine the directory where Chef will look to gather the SCOREC mesh and where to put the partitioned SCOREC mesh. Notice that this pre-written <code>adapt.inp</code> file points the meshFileName bz2 attribute to the mdsMesh_bz2 folder located in the simMeshToMdsMesh directory.
 Run the Chef bash script by entering the command <code>./runChef.sh 1</code>. This should output a <code>1-procs_case</code> directory, an <code>mdsMesh_bz2</code> directory, and a <code>chef.log</code> file.

@@ Line 22: / Line 22: @@
 === A few helpful video tutorials===
-[https://fluid.colorado.edu/tutorials/PHASTA_workflow_RB.mkv	PHASTA_workflow_RB.mkv	]
+[https://fluid.colorado.edu/tutorials/tutorialVideos/PHASTA_workflow_RB.mkv	PHASTA_workflow_RB.mkv	]
 [[Tutorial_Video_Overviews#PHASTA_workflow_RB.mkv|Video Notes]]
@@ Line 28: / Line 28: @@
-[https://fluid.colorado.edu/tutorials/RajDemoPrepSolvePost.mov	RajDemoPrepSolvePost.mov	]
+[https://fluid.colorado.edu/tutorials/tutorialVideos/RajDemoPrepSolvePost.mov	RajDemoPrepSolvePost.mov	]
 [[Tutorial_Video_Overviews#RajDemoPrepSolvePost.mov|Video Notes]]
@@ Line 34: / Line 34: @@
-[https://fluid.colorado.edu/tutorials/PrepSolvePostBLandC.mp4	PrepSolvePostBLandC.mp4	]
+[https://fluid.colorado.edu/tutorials/tutorialVideos/PrepSolvePostBLandC.mp4	PrepSolvePostBLandC.mp4	]
 [[Tutorial_Video_Overviews#PrepSolvePostBLandC.mp4|Video Notes]]
 [[Category:Chef]]

← Older revision		Revision as of 18:14, 11 June 2021
Line 30:		Line 30:
	[https://fluid.colorado.edu/tutorials/RajDemoPrepSolvePost.mov RajDemoPrepSolvePost.mov ]		[https://fluid.colorado.edu/tutorials/RajDemoPrepSolvePost.mov RajDemoPrepSolvePost.mov ]

−	[[Tutorial_Video_Overviews#RajDemoPrepSolvePost.mov\|Video Notes]	+	[[Tutorial_Video_Overviews#RajDemoPrepSolvePost.mov\|Video Notes]]

@@ Line 24: / Line 24: @@
 [https://fluid.colorado.edu/tutorials/PHASTA_workflow_RB.mkv	PHASTA_workflow_RB.mkv	]
-[[Tutorial_Video_Overviews#PHASTA_workflow_RB.mkv|Video notes of PHASTA_workflow_RB.mkv]]
+[[Tutorial_Video_Overviews#PHASTA_workflow_RB.mkv|Video Notes]]
@@ Line 30: / Line 30: @@
 [https://fluid.colorado.edu/tutorials/RajDemoPrepSolvePost.mov	RajDemoPrepSolvePost.mov	]
-[[Tutorial_Video_Overviews#RajDemoPrepSolvePost.mov|Video notes of RajDemoPrepSolvePost.mov]]
+[[Tutorial_Video_Overviews#RajDemoPrepSolvePost.mov|Video Notes]
@@ Line 36: / Line 36: @@
 [https://fluid.colorado.edu/tutorials/PrepSolvePostBLandC.mp4	PrepSolvePostBLandC.mp4	]
-[[Tutorial_Video_Overviews#PrepSolvePostBLandC.mp4|Video notes of PrepSolvePostBLandC.mp4]]
+[[Tutorial_Video_Overviews#PrepSolvePostBLandC.mp4|Video Notes]]
 [[Category:Chef]]

← Older revision	Revision as of 18:38, 18 September 2022
(No difference)

@@ Line 18: / Line 18: @@
 === Further Partitioning to N processes===
 By now you may be able to guess how to go about further partitioning your case into more and more partitions. If the user desired the end part count of 32 processes ( call that N), the next steps would mimic the latter with the subdirectory named 32-8-Chef and the splitFactor be set to 4.
-There are a few things to consider when partitioning an actual case you care about. It is tempting to make the successive split factors large as to have a fewer amount of repeated partions. As a general rule of thumb however, the splitfactor should not often exceed 8 especially on an unstructured grid. If it does, Chef will have a more difficult time splitting the elements evenly amongst the parts, causing an imbalance in the workloads from process to process, and therefore reducing the effectiveness of the PHASTA run. Secondly, when the mesh is large, the partitioning that is performed on the viznode should not exceed 32 parts. The successive partitionings past this amount should be done on larger machines. Sometimes if a mesh is large enough, the preliminary serial partition should be performed on a fatter node that what is available on the viz nodes (ie CU's summit resource).
+There are a few things to consider when partitioning an actual case you care about. It is tempting to make the successive split factors large as to have a fewer amount of repeated partions. However, the splitfactor should not often exceed 8 especially on an unstructured grid. If it does, Chef will have a more difficult time splitting the elements evenly amongst the parts, causing an imbalance in the workloads from process to process, and therefore reducing the effectiveness of the PHASTA run. Secondly, when the mesh is large, the partitioning that is performed on the viznode should not exceed 32 parts. The successive partitionings past this amount should be done on larger machines. Sometimes if a mesh is large enough, the preliminary serial partition should be performed on a fatter node that what is available on the viz nodes (ie CU's summit resource).
 === A few helpful video tutorials===