Spencer Cheleden Journal

final_poster.pdf

Activity Log

TOTAL TIME: ~147 Hours

  • 1-27: 8-11 PM Setup journal. Installed Paraview. Read this paper, about a use case of AR for an AI application, particularly about robot motion planning. Read about and linked to the hardware section of the wiki the Magic Leap 1, a wearable "Lightwear" device mentioned in this paper. The paper indicates the creation of a Unity mesh generated automatically by the Magic Leap 1.

  • 1-29: 8-11 PM Read the assigned Yurt pages: YURT Software, YURT Software Evaluation, and Data, Examples, and Collaborators. I'm thinking about looking at some of the data listed in the Data, Examples and Collaborators page: in particular, my interest was piqued by some of the point cloud data, as well as DinoYurt, which I have worked on a little bit. I also came up with some initial project sketches based on this research; these are listed below. I looked into some background stuff as well -- remember to link those papers when I have time.

  • 2/3-2/4: 10PM-12AM: Installed Unreal Engine. Brainstormed and listed some basic software evaluation metrics. Fleshed out the Refined Project Ideas subsection, although that name might be a bit of a misnomer, it will need some more work.

  • 2/5: 2-5PM: Met with Zhicheng. Discussed the implications and background of the research. Gained some groundwork for what kinds of visualizations needed to be done. Did background reading on his groups' research, and did some web searching on some of the math behind their numerical solutions.

  • 2/7: 2-4PM: Did the Unreal Engine tutorial on the Wiki. Added to the Software Metrics section below.

  • 2/10: 5-7PM: Created my project plan/initial presentation. Visualized a test data set of the same format as the ones I intend to use in Paraview.

  • 2/12: 2-3PM, 7-8PM: Met with Zhicheng to discuss details about the first dataset he gave me, along with further information about the project in general. Wrote up this information in my handwritten journal, to be transferred later to the online portion. Read the paper below (Williamson 1996). Created the video embedded here.

  • 2/14: 2-3PM: Attempted to get Paraview working in the Yurt. Ran into some version issues.

  • 2/19: 2-6PM: Got the Paraview demos working in the Yurt. I had various incorrect modules loaded, which took time to figure out. I loaded some of the toy datasets in the Yurt. I figured out that the version in the Yurt does not support Tecplot Binary Files, as the required reader is not loaded. I found the source code for this reader in the Paraview source repository online, and may look into rebuilding Paraview with this code. I updated my journal, created this page about Multiphase Flow Data that I am using to be one of my deliverables, and created my presentation. I also tried loading older versions of Paraview in the Yurt, without success.

  • 2/20: 9-10AM: Did Journal Evaluation.

  • SUMMARY 2/20: Hours worked: 23. Deliverables on track? Partially. (See below for further eval.)

  • 2/24: 3-6PM: Worked further on Yurt stuff for Paraview. Read through source code, etc to try to get fix for .plt files. Mostly unsuccessful.

  • 2/26: 12-3PM: Met with Zhicheng. Showed him Yurt. Talked over dataset, background, etc. Further developed idea of how to flesh out the Yurt portions. Started conceptualizing Paraview views that could be useful locally. Asked Zhicheng for the set of data as .vtk files as alternate route.

  • 2/29: 5-9PM: Got next dataset. Created multiple angles, shadings, etc. for each timestep. Created animations of these different perspectives. {Need to upload these!}

  • Sometime in between (forgot to track) ~2-3 Hours: Setup Paraview Yurt Tutorial page.

  • 3/4: 4-8PM: Got Paraview working in the Yurt for the data installed. Viewing ~20 time frames. When I wasn't in the Yurt, began developing the Paraview Yurt megathread and centralizing documentation.

  • 3/8: 3 Hours: Generated Paraview save states for Zhicheng as I realized that it would be too slow for the Yurt to render the large datasets for subsampling.

  • 3/9: 4 Hours: Met and showed Zhicheng the Yurt demo. He was rather disappointed. Created my presentation. Published the beginning portion of my deliverables to the coures wiki. Linked here.

  • Note: I switched to weekly time-logging here, because I didn't write down in as much detail what I was doing day-by-day and to be my days kind of blurred together for the project going forward.

  • Week of 3/8: 13 Hours. Prepared project plan. Met with David and others to figure out what I wanted to do for my second project. Met with Ella to begin to understand Paraview builds. Tried to figure out Paraview versioning in the Yurt.

  • Week of 3/15: Moving out of Brown Week, 2 hours. Met with Ella again. Looked cursorily at the instructions on how to build Paraview in the Yurt.

  • Week of 3/22: Spring Break, 0 hours

  • Week of 3/29: 10 hours: Met twice with David and Ella about work going forward. Attempted to figure out how to get Paraview working in the Yurt. Viewed my data remotely. Viewed the bunny data. Saw that performance was too slow working with the version of Paraview currently installed. Met with Camilo about how to get future versions in the Yurt.

  • Week of 4/5: 10 hours: Built an earlier version of Paraview by myself. Had to deal with module issues and linking issues. Documented the build process for Paraview. Had the incorrect submodules loaded. Collaborated with Ella and Camilo to figure out a working build.

  • Week of 4/12 15 hours: Successfully built a version of Paraview. Tried to run this version in the Yurt -- it didn't work. Viewed my data in the Yurt. Observed frame rate decreases. Attempted cursorily to get head tracking working and failed. Documented the issues in the build process. Met with David and Ella about Yurt issues.

  • Week of 4/19: 20 hours: Worked with Ella on setting up submodules and git tracking. Debugged the broken version of Paraview. Isolated the various module issues and figured out a consistent set of modules that allowed the build to be produced. Got head tracking viewable in the Yurt, with a pretty low frame rate. Set up instructions of how to build versions of Paraview from the Yurt. Figured out the requisite git stuff to be able to do this. Met with David and Ella about Yurt issues.

  • Week of 4/26: 20 hours: Figued out how to perform scripting for Paraview on my local machine. Debugged some python issues doing this. Figured out that the native paraview interpreter was a better way to do my in class activity as compared to the pvpython executable which hid rendering in some background process. Designed my in-class activity. Created some fun python scripts for Paraview. Did my in-class activity. Tested head tracking for different sets of data. The framerate appears to be moderately improved. Began work on figuring out a new version of Paraview - 5.7.

  • Week of 5/3: 10 hours: Looked into some module changes for loading Paraview for MPI specifically. Assisted Ella with preparation for new versions of Paraview (still stymied on this) Prepared final presentation, poster, etc.


Journal Evaluation (Spencer self-eval) 2-20-20

  • Journal activities are explicitly and clearly related to course deliverables

    • 3.5. There is a lot of background work done here, not all related directly to course deliverables. I did create and write some for the page that will describe my dataset and how to work with it (linked under the 2/19 bullet point). I also did get some Paraview toy datasets viewable in the Yurt, although these are not up for viewing as of yet.

  • Deliverables are described and attributed in wiki

    • 3.5. Slightly behind schedule here. I need to continue updating this page, as well as most critically fleshing out the Paraview Yurt documentation page. This Yurt Paraview page (which doesn't exist with my name on it as of yet) should be updated with what I have learned so far. I did add the meeting notes with Zhicheng below in my journal; I should probably take the time to update these and place them on a different page somewhere in the site.

  • Report states total amount of time

    • 5. I think this is quite clear.

  • Total time is appropriate

    • 4. Pretty much on schedule. I expect time spent to ramp up a fair amount in the coming weeks, especially as I spend time debugging in the Yurt and trying to get the appropriate reader functioning in Paraview or alternatively begin to work on some kind of presentation. I also expect the time spent working on deliverables specifically to begin to ramp up quite significantly.

Williamson 1996 (Background Paper)

Williamson_ARFM_96 (1).pdf

Zhicheng Meeting Notes

These are some (pretty unorganized as of yet) notes about the feedback that I have gotten from collaborators thus far.

  • The test visualization I did initially looks useful. The video is described as "shows the vortices shedding from a vibrating cylinder subject to uniform incoming flow at Reynolds number 1000." Need to do background as to what this actually means.

  • Further visualizations could make better use of color.

  • I need to ask for further datasets, as I think what the group actually wants out each dataset is not super in-depth, and the overall trends from multiple simulations, especially developing more realistic/intense boundary conditions may actually be more useful.

  • The current simulation is described as being for Ocean pipelines, with both a constant velocity current boundary condition at one end, along with sinusoidal transverse oscillation. The idea is to look for rupture due to resonance phenomena by investigating the vortices shed into the surrounding fluid by the cylinder, in particular in looking at phase differences between vibrations arising in the pipe by the motion of the current and the induced sinuisoidal vibrations. This should ultimately be done by looking at vortices that develop.

  • To this end, I need to figure out a way of communicating this in a simpler, more efficient way with the class that is somewhat clearer to everyone involved.

  • Schedule next meeting for further datasets, possible looking at data in the Yurt ASAP.

Initial Project Ideas

  • Project Idea #1: Continue development of dinoYURT, working with colllaborators. If possible, I would like to source and process my own data set for viewing, Maybe consider adding some feature to dinoYURT that would be relevant to the dataset in question that I might come up with.

  • Project Idea #2: Look into possible visualizations of architectural data. The idea is to try something like Google Earth's building view, but be able to actually step through architectural plans. There is an interesting software package called IrisVR that may bear looking into.

  • Project Idea #3: Something with LIDAR or point-cloud data. I need to flesh out this design further.

Further Project Ideas

  • Project Idea #1: Dinoyurt Work: This project will consist of refining or adapting dinoYURT to better visualize different kinds of data. Most likely, it would involve the application of the previous work to a new kind of data, potentially spawning a new application. I will need to identify some feature of the relevant dataset to add to DY (or modification to make), make the modification, and see how this changes visualization.

  • Project Idea #2: Using MinVR to Port ???: Need further ideas.

  • Project Idea #3: Matlab I have an interest in visualizing some kind of statistical analyses of various trends -- not entirely sure how viable or useful this will be in the

Project 1 Plan

Linked into a subpage now!

Initial Project Proposal Evaluation (evaluated by Zach)

  • Will the project deliverables be useful and significant?

    • Yes, each step adds to the progression.

  • Will the project activities improve the potential quality of the project?

    • Potentially, if class has helpful input.

  • Will the project activities help identify and reduce project risks? Risks often involve external dependencies that end up not being met or over-optimistic estimates of time required.

    • Yes, early on there is an attempt to get the software running.

  • Will the project activities themselves add deliverables to the wiki?

    • Yes, in the form of guide and ways to streamline getting data into it.

  • The proposed project clearly identifies deliverable additions to our VR Software Wiki.

    • Yes, we're shooting for a complete data-> parayurt pipeline

  • The proposed project involves previously unavailable Yurt data visualization functionality.

    • Yes, there is no parayurt

  • The proposed project involves large data visualization along the lines of the "Data Types" wiki page and identifies the specific data and software that it will use.

    • No identify

  • The proposed project has a realistic schedule with explicit and measurable milestones at least each week and mostly every class.

    • Yes, unless getting parayurt will be difficult

  • The proposed project has resources available with sufficient documentation

    • Yes!


Spencer Project Evaluation by David 02/07/20

o The proposed project clearly identifies deliverable additions to our VR Software Wiki

3 Your plan implies some deliverables/additions to the wiki, but it doesn't really describe them explicitly. The plan is also very sparse. I'm assuming you are referring to Zhicheng's flow data, but you don't say that. Having only the milestones is a bit limiting :-)

o The proposed project involves previously unavailable Yurt data visualization functionality

4 I think so, but it's a little hard to tell

o The proposed project involves large data visualization along the lines of the "Data Types" wiki page and identifies the specific data and software that it will use

5 If flow data, then ok?

o The proposed project has a realistic schedule with explicit and measurable milestones at least each week and mostly every class

4 Seems ok, but dependence on ParaView working in the yurt is pretty high. I suggest trying that out to evaluate how much work it will be would be a good early activity.

o The proposed project includes an in-class activity

4 More structure for what this will be will be good.

o The proposed project has resources available with sufficient documentation

4 Paraview is my biggest concern here.

o Also add any additional thoughts guided by the questions in the homework wiki entry.

Again, more proposal beyond just milestones, please!


Spencer Project Evaluation by Ross 02/07/20

o The proposed project clearly identifies deliverable additions to our VR Software Wiki: 3

Would be beneficial to write out deliverables more explicity.

o The proposed project involves previously unavailable Yurt data visualization functionality: 4

Trying to visualize fluid simulations with Paraview would be very interesting!

o The proposed project involves large data visualization along the lines of the "Data Types" wiki page and identifies the specific data and software that it will use: 5

o The proposed project has a realistic schedule with explicit and measurable milestones at least each week and mostly every class: 4

Milestones are explicit; however, they could include more details, such as what data is being tested on what days.

o The proposed project includes an in-class activity: 4

It would be useful to fleshout your class activities for your project presentation,

o The proposed project has resources available with sufficient documentation: 4

Paraview is somewhat finicky at times, so visualizing the fluid data in the YURT might be pretty challenging. However, it's worth a shot!


Spencer Evaluation by Giuse 2/8/20

o The proposed project clearly identifies deliverable additions to our VR Software Wiki

3 To me there is one clearly deliverable at the end of your project on Paraview, I think you could add/update pages on data with fluid vector data, and where you intend(sub-section/site location-wise) to add your documentation

o The proposed project involves previously unavailable Yurt data visualization functionality

5 Yes 100%

o The proposed project involves large data visualization along the lines of the "Data Types" wiki page and identifies the specific data and software that it will use

5 Clearly explained!

o The proposed project has a realistic schedule with explicit and measurable milestones at least each week and mostly every class

4 In addition to what data on what days, perhaps data evaluation metrics as well?

o The proposed project includes an in-class activity

5 I like the activity

o The proposed project has resources available with sufficient documentation

4 I believe it is possible!

Software Evaluation Metrics

  • Note: for this list, I attempt to list metrics in a kind of chronological order, the idea being that the insights from these metrics might be gleaned one after another.

    • Installation

      • Cost (free or paid, licensing model, etc.)

      • Open- or closed-source

      • Difficulty of installation (qualitative, e.g., complex dependencies also simple quantitative measure of install time on various systems)

    • Interface

      • Ease of use (how quickly a new user can understand what they are using)

      • Modularity

    • "Power" (need to think of a better name for this)