So I want to give you acknowledgments. What is it? It's a EMR that provides access, and the keyword is access. All we want to do is to be allowed in. Once we're in, we don't ask the EMR vendor to do anything else. We provide the capabilities that we've heard about today and that are illustrated on this slide. Now, we've heard and we've seen the previous presentations. You can do a lot of these things, the collection transfer integration, the delivery of support. But some of the things like the patient empowerment, the better understanding, the family social networking, these are things which are really not done well within EMRs. And we think it's better if we think about bringing applications from the internet into an EMR to do that. So we have developed a relationship. We got permission from Epic. In March next year, Epic's 2010 release will enable health heritage. Anyone who buys Epic's 2010 release will automatically be able to, if they desire, to turn on this application, which is external to Epic, but which has a door into Epic. What are the principles of this system? It attains a limited amount of essential data from the primary sources. We started with family history and cancer risk assessment because you'll see we were funded by the NCI, but we plan to go obviously beyond that. We understand what the data represents. We input the data in a way to either new or existing support tools. We deliver it in ways that people can understand and then we constantly monitor, approve it. We've heard this throughout this meeting today. This is what clinicians want. This is what consumers want. As we said, we are supported by the National Cancer Institute in this initial release, so we concentrated on all the common cancers and the syndromes that are associated with that, linking family history to these cancers. The nice thing about that is family history also serves as the foundation, as you all know, for genomic medicine beyond cancer and in all the other specialties. Let's look very briefly at each of these principles. We obtain a limited amount of essential data from the various primary sources, including EMRs. With our Epic agreement, what we're able to do is we're able to go into the Epic EMR, pull out medical, surgical, family history, laboratory data, and we're able to pull that into our application and we're able to return to Epic risk results and recommendations and pedigrees to the physicians and to the patients who are using MyChart, which is the tethered PHR, which is associated with Epic. There's a single sign-on. A patient activates this service. This is a patient-oriented decision support application because we think you need to involve patients from the very beginning. They sign-on to their MyChart aspect of Epic. They're automatically registered then into health heritage. They have to go to health heritage and say that they want to use it. They request from health heritage the ability to pull their medical history into their chart from Epic, their documented medical history, when they had cancer, if they had cancer, the age, and the type that it was. If they had a colonoscopy, how many polyps did they have during that colonoscopy? All that information is pulled into their medical record and then we encourage them to say, okay, let's go to their family members and have them do the same thing and in the process we will create an electronic family tree. So we have a family tree which is populated with data from the primary sources in the record, authentic data, and which is integrated in a comprehensive way. That's always been a barrier. We have system interconnectivity. We, providers access, can access health heritage from hyperspace within the menu or toolbar within their Epic system and they can see both provider and patient context. So there's transparency across the different systems. Data exchange, what are we doing? We are moving from Epic data which is in their problem list, their medical history, their patient demographics. We're moving data which is in textual format path reports, operative reports, and we're taking those results and we're moving them into health heritage to populate an individual's personal medical history. We are then returning to Epic, which is an HL7 message, a narrative text containing what the recommendations are and we're depositing that as a test result into Epic that the clinician can look at directly. How do we know what we have when we pull this data from Epic? And this is a very important, I think, concept. We initially took the information that we needed to do family history and risk assessment in those cancer syndromes and we mapped them to UMLS, SNOMED concepts. Then we took what is a constant roadblock in this field which is Epic has a problem list or a diagnostic list which is maintained by a separate vendor and it's a proprietary system that has no relationship to anything in the world. So you automatically say, what am I going to do with this huge diagnostic master file that is linked to nothing? Well, what you do is you map it to SNOMED and that capability is increasingly there and then what we did is we used the NCBO bioportal to look at the parents, those SNOMED codes who are in the Epic diagnostic file that were also needed to be in health heritage. We identified 4,700 so that now when we make a web service call into Epic and ask for this information and if one of those SNOMED codes that we're looking for is present then we'll set the attribute that we need in the decision support system in health heritage to present. So we've overcome this barrier and increasingly being creative you can go into systems that have proprietary data formats that are not standardized and you're able to achieve understanding of what that data is. Now, we input that data into existing or newly designed decision support tools. We heard that decision support tools are not used. There are thousands of them out there in paper that are not used because they're not connected into the system. In many cases it's not necessary to design new ones. We just want people to use the existing ones with the appropriate data. For our purposes we have a very good existing one. The NCCN guidelines, there are hundreds of pages very detailed, wonderfully precise guidelines. They're completely unusable by any human being because they're so long and they're so detailed. So what we did is we made them computer friendly. We took and we developed decision trees based out of the current literature. We just didn't use NCCN. We updated it where we thought was appropriate, although it keeps itself updated really, really very, very well. And we did a decision trees for all of the specific cancers and all the specific syndromes. This is a substantial undertaking. Fortunately it only needs to be done once, but this is just the top of a decision tree here that actually if you would print it out it would go about 16 feet long in order to take all the different permutations and possibilities into it. But what it does is it automates it. You don't have to go to those hundreds of pages of guidelines. It automatically takes the data that we've collected. It puts it through the NCCN process and it comes out with those specific risk and recommendations. And it delivers the output in ways that can be understood, stored and easily shared by consumers and clinicians in trusted ways. This is something else that we've heard from a lot of people that they want to be able to do. So after we process the system we collect the information from individuals and from their family members with sufficient precision to be able to do a risk assessment and recommendation. We can put people into risk stratification. And we're trying to look at both ends of the spectrum. We're trying to recognize that there are many millions of individuals who because of their individual patient characteristics really don't need routine screening with the frequency with which it's currently being done in this country. And we're trying to suggest to some of those individuals there may be the ability to reduce the frequency of their screening safely. At the other end we want to make very sure that we identify very early and very soon those individuals who indeed because of biological or hereditary predispositions are an extremely high risk for developing problems. And they are identified early in the process frequently through family-based structures and analysis of the family history and that they're given the appropriate advice early on to be able to access the services that they need. We present that report about what they should do to the patient and then we ask the patient whether they want that report to go to their clinician and which clinician they want it to go to. It's a very important process of patient control. It's not how things are traditionally done. Traditionally things done, test results show up in EMRs and the doctor decides when the patient can see it or it defaults to having the patient see it after a few days. We think this is patient information. It's their family information. After they know what the NCN recommends for them then they decide who they want to send it to and that test result then goes to the clinician. They have a number of links that they can go to when they receive that result. We also are building in crowdsourcing which is trying to link them to sites like patients like me where they can exchange some of their information and data and get some input beyond their specific family structure. And again, everything that the patient sees and including a more sophisticated provider report can be accessed by the clinician. The print is too small for you to see but there's a link on this page in Epic for them directly to go to the healthcare to the genome electronic and medical record. So we're obviously monitoring the use and impact of this as we roll it out into communities. We've already done the initial clinical trial which looked at the performance of our risk algorithms and recommendations versus an expert genetic team and a genetic counselor collecting information. So we had people for whom that was done in a very separate process and then we applied our health heritage and we demonstrated that we were as good as that process. So we think we have clinical validity. We're now going to test vigorously for clinical utility by our first implementation is at North Shore University Health Systems in Chicago, a very sophisticated system which has had Epic for a long time. But we hope then to go into other Epic sites. We hope to go beyond Epic. We're developing a relationship with Ancestry.com so that we can actually think about soon going into paper-based offices and extracting information from paper forms which as we all know, the majority of physician's offices in this country are still paper-based. So we think there's a great future for using EMRs as a source of information but not relying on them as the way to build decision support. Thank you. Questions? So going back to the family history information you indicated the sharing platform that you have. Are you reliant on the other relatives providing information or does the health heritage consume a more traditional patient-entered family history? The subset of that question is, does the health heritage support consumption of other tools that run on the current AH? Yeah, we link to the Surgeon General's, for example. And a person can enter a history themselves and the system has annotation where they did this information come from the EMR directly? Was it entered by the patient? Every family member has to give permission for their information to be transferred to their other family member. It's like Facebook. You have to friend someone to share information. It's the same concept. So yes, we are able to take information from different sources and the other thing that we've done is we allow patients to meta-tag data. We don't allow them to change any of the information in their medical record. But if they have a diagnosis or they see a problem that appears in their record by virtue of it's being transferred to us and they say, you know what? Yeah, they made that diagnosis a couple of years ago but nothing ever really happened with that and there can be this little meta-tag that sits beside that note and the clinician can decide to do what they want with that but at least when someone looks at it there's some annotation from the patient. We think that's also going to be a very positive way to help improve the quality of the data in these EMRs. I may have missed this or just need clarification. You said that once you develop a report with a risk assessment it goes directly to the patient and then the patient decides if they want it sent back to like a physician. Did they want it to go to their primary care physician, their OBGYN? Who did they want it to go to? So in the epic chart, did you just say like does some sort of notification go back at all? Yes. Okay. So notification will go back to the physician that this has been done and they're at high risk or does the physician have to go through the process? No. The physician gets a specific report that tells them this is what they are, this is the recommendations that need to be done. It's very direct. Only after the patient authorizes that to pass over to their provider. If they don't authorize it at all you've extracted the data from Epic. Nothing goes back to Epic. It sits in Epic but it sits in my chart. It sits in the personal health record of Epic. It doesn't sit in the clinicians component of Epic. The patient has to authorize that it go to that clinician. Is there like a legal liability issue from the physician's perspective? This is the patient's information. And one thing you have to realize is once the information is extracted from an EMR and it goes to an external application, it's your information. It's on your desktop. It's yours. You own it. You control it. So but if they have that information, it's from Epic and the physician has looked at Epic and not put it together themselves, are you opening up a door for a liability issue that the physician did not recognize? Like if time goes on and the patient does not say, I want this to go back. We hope that the communication, the two-way communication that sets up that the physician knows their patient is registered for health heritage. They know that they've done this. There's two-way communication that sets up there. But again, we think that as we move forward, the concept of patient control over their information is going to be increasingly important. Thank you. Okay, we're out of time.


It enables researchers to predict the presence of higher-order EPS, as well as to tune them for specific applications. Additionally, this method can be extended to study EPS in higher dimensions and reveal complex anisotropy near these degeneracies. This article was authored by Rhymika Jeswal, Ion Banerjee, and Awat Heshnir Ion.


Hi, everyone. This is the Circuit Python Weekly for September 12, 2022. This is the time of week where we get together to talk about all things Circuit Python. I'm Paul Cutler, and I'm a member of the Circuit Python community. Circuit Python is a version of Python designed to run on tiny computers called microcontrollers. Circuit Python development is primarily sponsored by Adafruit, so if you want to support them and Circuit Python, please consider purchasing hardware from Adafruit.com. This meeting is hosted on the Adafruit Discord server. You can join anytime by going to adafruit.com. We hold the meeting in the Circuit Dev Text Channel and the Circuit Python Voice Channel. The meeting typically happens on Mondays at 2 p.m. Eastern and 11 a.m. Pacific, except when it coincides with a U.S. holiday. There's a link to the calendar you can view online or add to your favorite calendar app. We will also send out notifications about upcoming meetings via Discord. If you'd like to receive these notifications, ask us to add you to the Circuit Pythonista's Discord role. There is a notes document that accompanies the meeting and the recording. The notes document contains time stamps to go along with the video, so you can use the doc to view only the parts of the video that interest you the most. The meeting tends to run 45 to 60 minutes, so this gives you the option to skip around. After each meeting, we'll post a link for the next meeting's notes document in the Circuit Python Dev Channel on the Adafruit Discord. Check the PIN messages to find the latest notes doc so you can add your notes to the following meeting. If you wish to participate but cannot attend, you can leave hug reports and status updates in the document for us to read during the meeting. The meeting will be held in five parts. The first part is community news. This is a look at all things Circuit Python and Python on hardware in the community. It's a preview of our Python on microcontrollers newsletter. The second part is the state of Circuit Python, libraries, and Blinka. This is a statistical overview of the entire project. It's a chance to look at the project by the numbers, separate from what we're all up to. The third part is hug reports. Hug reports is an opportunity to highlight the good things people are doing, taking the time to recognize the awesome folks in our community. The fourth part is status updates. Status updates is an opportunity to sync up on what we've been up to. We'll take a couple minutes to talk about what you've been doing in the last week, either personal or Circuit Python related and what you'll be up to over the next week. The fifth part is in the weeds. In the weeds is an opportunity for more long form discussions. These discussions can come out of status updates or be something you've identified ahead of time is too long for a status update. And that covers how the meeting will go. With that, we will go over to community news. Raspberry Pi just released a new version of the Raspberry Pi operating system. It's mostly bug fixes, but it does have one new big feature support for the Pi Camera 2 library. It can only be used with newer versions of the Raspberry Pi OS, but the camera library is supposed to be much easier to use than the original. Next up is Picon UK 2022 is happening this weekend, Friday through Sunday, September 16th through the 18th. There will be a Python on Hardware community showcase this Sunday where you can bring your projects to share. If you're in the UK or in Wales, check it out. And the last one is probably my favorite, which is a steam powered Raspberry Pi Pico. Maker Mike Bell has used a small steam powered engine to power a Raspberry Pi Pico along with a few accessories. The Pico can run for about 12 minutes before the water in the boiler is all gone. The Circuit Python weekly newsletter is a Circuit Python community run newsletter emailed every Tuesday. The complete archives are available online and then the link is in the notes document. It highlights the latest Python on hardware related news from around the web, including Circuit Python, Python, and MicroPython development. To contribute your own news or project, edit next week's draft on GitHub or submit a pull request with the changes. I submit a PR every week to Ann and if you need any help, I'm always there to help you as well. You may also take a tweet with Circuit Python on Twitter or email cpnews at adafruit.com. Alright, the state of Circuit Python libraries in Blanca. Last week we saw 31 pull requests merged from 20 authors, which is great. A couple new names that I didn't recognize is, and I apologize if I pronounce any of these wrong, Pepin Divos, Rivkis, Simple Theory. We had 10 reviewers and we had 24 closed issues by 10 people and 18 new issues opened by 14 people. Dan, will you do the core? Sure, hold on. I've lost my window. Alright, let's go ahead and talk about the core, which is Circuit Python core, firmware. In the past week there were 13 pull requests merged. There were 11 authors. A couple of new ones I see are Pepin Divos and maybe that's it. The other ones I've seen before, 5 reviewers. Thanks for Microdiv for coming back into review and there are currently 19 open pull requests. A lot of those are on hold because of things beyond our control, kind of third-party things. There were 7 closed issues by 4 people and 10 opened by 6 people, so we're getting behind a little bit, but it's not terrible yet. There are 572 open issues and there are 5 active milestones and 6 issues not assigned a milestone, which we need to triage. Okay, that's it. Now I'll turn it over to Catney for the library update. Thanks, Paul. This applies to all of the Adafruit Circuit Python libraries, which is everything that starts with Adafruit underscore circuitpython underscore, as well as a few extras including the community bundle and our cookie cutter. For the last week, we had 15 pull requests merged by 8 different authors and 8 different reviewers. The oldest merged pull request was a week old and a majority of them were 0 or 1 days, so we're still getting through some of the aging ones, but we are keeping up pretty well with everything else. And that leaves us with 38 open pull requests. In terms of issues, there were 13 closed by 7 people and 5 opened by 5 people, leaving us down a bit with 622 open issues. 130 of those are good first issues. If you are interested in contributing to Circuit Python on the Python side of things, check out circuitpython.org slash contributing. You'll find all this information and more including open pull requests and open issues. If you're interested in reviewing, check out the open pull requests. If you have the hardware, test it. If you don't, check out the code, see if it looks right to you. Check it for spelling, syntax, etc. And leave us a comment and let us know you did. Once you're more comfortable with that, we can talk about leveling you up to our review team. If you want to contribute code or documentation, check out the open issues. If you're new to everything, good first issue is a great place to start. We have a guide on contributing to Circuit Python using Git and GitHub, and we're always available on Discord to help out, so don't let that part intimidate you. You can search the open issues either by searching the page or you can search by label and clear down that 622 issue list to something more manageable. In terms of library updates in the last seven days, we had no new libraries and a series of updated libraries that I will not read off. And that's what I've got. Thanks, Gany. Melissa, will you cover Blinka for us, please? Sure. So Blinka is our Circuit Python compatibility layer for Raspberry Pi, MicroPython, and other single board computers like Raspberry Pi. And this week we had three pull requests merged by three authors and two reviewers. There are currently nine open pull requests, and there were four closed issues by one person and three open by three people, leaving a net of 84 open issues. There were 11,826 PiWheels downloads in the last month, and we are currently supporting 91 ports, though I expect that to go up here this next week. And that's it. Awesome. Thanks, Melissa. Now it's time for Hug Reports. Hug Reports are a chance to highlight folks in the Circuit Python community for doing awesome things. I'll start, and then we'll go down the list alphabetically to give everyone a chance to participate. Text-only are missing the meeting, but have Hug Reports in the notes document. I'm happy to read them off. So I've got a couple notes. I had to leave the meeting early. Saturday morning we did the community help desk. So thanks to everyone who showed up and covered my time there as well. I got my COVID booster Friday, and it hit me hard Saturday morning. Thank you to Dan and Katny for the time-stamper code that makes hosting this meeting way easier in a group hug. Next up we have a group hug from 2231 Puppy, who's text-only. After that is C Grover, who is also text-only. He says thanks to everyone who participated in the Circuit Python community help desk. Special thanks to those who helped and continue to diagnose a challenging display drawing speed and brightness issue with a titano running 8.0 beta zero. Dan? Okay, thanks. Thanks to MicroDev and Gambler, Mark Gambler for recent fixes to Circuit Python and follow-ups on other things related to that. Thanks to Jeff for tracking down the true cause of a pre-commit build environment mystery. Lee Atkinson had trouble with this. And it was very confusing because it works for some people and others, and it has to do with virtual-env and v-env and a whole bunch of... and Debian packages, and it's very confusing. But Jeff figured it out. Thanks to Neridoc and Tetric, who are working on PRs and support, a whole bunch of things. It's really great to have people working on that stuff. Really, really helpful. Thanks to RetiredWizard and BillADAT, who's... they're testing out new features and finding bugs in the new code that we've been PR-ing. Thanks to Catney, who's been persevering, trying to find the mysteries of read switches that one might buy on Amazon or other places. And she can tell you more about that later. And thanks to you, Paul, for volunteering to be a weekly meaning host. That's really great. It spreads the load. Really wonderful. Thank you. You're welcome. Thank you. Next up is DJ Devin3 and then FoamyGuy. I'd like to send a hug to HopCappy for helping me get past a lot of errors and setting up MySys2 and TO for Windows VS Code. Anecdata for showing me the air of my ways with Socket Pool and a great way to remember it in the Highlander voice. There can only be one pool. To Neridoc for always correcting me whenever I say anything wrong. He's been my mentor for a while, even if he doesn't realize it. MacGyver, the developer of TO for personally coming into Discord and working on package errors, feature updates, and submitting a PR to MySys2 so the default TO install in MySys2 isn't a four-year-old version. Hopefully we'll see an update for MySys2, get pushed out for his efforts, which should make things a little easier for TO users on every platform, but especially for Windows. A hug report to Katni for working on the Laura Mailbox project. I see how deep she's had to go into the code, and I just want to send her a word of encouragement and looking forward to using her upcoming learner guide for my own Mailbox project. To Mark Gambler for sending me a show and tell badge. I've honestly always wanted one, and I'm giddy with joy for receiving it. It's like a newbie badge of honor, and I will display it with pride. To Cgrover and Foamy Guy for initiating a community-wide bug hunt during community help desk on Saturday morning. I learned a lot about bug hunting, and it was extremely helpful. To Paul Kuttler and Tammy Mikes for hosting the Saturday morning session of Community Help Desk. It was totally worth waking up for coffee and a chat on a Saturday. And to everyone else at Adafruit for helping turn dreams into reality every single day. Thanks, DJ Devon3. Foamy Guy, you're up next. Alrighty, thanks Paul. A hug reports this week to Tammy, Keith Cgrover, DJ Devon3, Mark Gambler, to you Paul, and to Dexter, as well as anybody else who I may have missed that participated in the help desk. I had a great time with that over the past weekend. I'm looking forward to getting the next one in when we do. Over on GitHub, this user's name is kind of short for Snakey Maker Cat. Thank you to them for sleuthing and figuring out a pretty intricate issue with the display text library and submitting a fix for it as their first contribution that I could see across Circuit Python. So congratulations and thank you to them. Thank you to you Paul for joining the rotation to help host this meeting. Thank you to Cgrover, Mark Gambler, DJ Devon and anybody else from the help desk or any of the PRs or issues at this point really, who helped troubleshoot and look into the strange display drawing speed issue that's cropped up and then a group hug for everybody. Thanks. Thanks Foamy Guy. Catney? Alright, so a super huge hug and thanks to Paul Cutler, our host, for joining the Circuit Python weekly meeting host rotation and for jumping in by hosting today. Six or seven hugs to Neridoc and Argonne Blue on Discord for helping me multiple times over the weekend with Circuit Python issues and weirdness that I was running into. To my bestie, Brian, for helping me with the Circuit Python program to identify read switch terminals. To everyone who hosted the Circuit Python community help desk this past weekend, I hear it was amazing and I look forward to hearing more. To Dan for trying to help me understand read switches and for making suggestions regarding the read switch explanation of my upcoming guide as well as verifying that I explained time alarms and PIN alarms well enough in the guide also. And to Oats and Honey, Malhor and Ember and Todd bought on Discord for helping me with a battery voltage drain question. It was a little bit of a weird one and everybody had some input on it and it helped me out and gave me the answer I needed and a group hug for everyone else. Thanks, Katny. I will read off the next couple starting with Keith the engineer. He has a hug report for Tanny Makes Things. Myself, Mark, DJ Devon 3, Fome Guy, Maddie T, C Grover and everyone involved with the community help desk. It was a great experience and I'm really looking forward to the next one. A hug report from Mark, a.k.a. Gambler for confirming a bug that Keith ran into with the Metro ESP32-S2 and DJ Devon 3 for testing it on the ESP32-S2 board that they had and highlighting that the bug doesn't occur on all ESP32-S2s. A hug report for Anecdata for a really good sample code in a GitHub issue that made it easy to test if my bug was one that was addressed in an already opened issue. And lastly to the awesome helpful community as a whole. Everyone's support makes working on projects so much more fun and special. Next up I will read off Mark a.k.a. Gambler. He has a hug report for Tanny Makes Things, Keith, Fome Guy and me and everyone else who was at the community help desk. A hug report for C Grover and Fome Guy for poking around the display shapes. Pi Portal-Titano issue on Saturday which turned out to be a stranger but larger performance issue than any of us thought at first. Next up we have Tanny Makes Things. Thanks. So I have the hug reports for Paul Cutler, Keith, the EE, Fome Guy and everyone else who joined in the community help desk. And also to Paul for stepping in to record at least part of the event when my computer suddenly refused to see any valid audio capture devices in OBS which I think is a problem with the Mac OS beta that I'm running unfortunately which means it won't be fixed until the beta is fixed. Hug report to Fome Guy and everybody else who was working on that display performance issue. I never did check back yet and see what the ultimate cause turned out to be but that was some amazing troubleshooting and a group hug to the community for being awesome. Thanks. The last one we have is from Tech Trick who's text only so I'll read those off. The first hug report is for Tanny Makes Things for hosting the community help desk this past weekend. Sad I couldn't make it but excited to help with the next one. Cedar Grove Studios for the new library in the community bundle. Hug report for Ducky the scientist and Fome Guy for fixing the data notation for the RTTL library. I have a dependent project where I noticed the bug but never confirmed it so I'm glad that my songs will finally play correctly. And lastly a group hug. Next up is Status Updates. Status Updates is our time to sync up on what we're doing. I'll start and we'll go through the list alphabetically to give everyone a chance to participate. When I call on you take a couple of minutes to talk about what you've been doing since the last meeting and what you'll be doing up until the next meeting. This is also an opportunity to provide tips and tricks relevant to what people are working on. If a discussion becomes too much for Status Updates we will move it to in the weeks. All right, last week I interviewed Brayden Lane for the Circuit Python show. That'll come out in about three weeks. He's got some really cool Circuit Python products. Todd Bodd and I announced that we're creating a new podcast called The Bootloader which will debut in two weeks. It'll be news and stuff we think is interesting that we'll share from the maker and tech communities. And lastly I'm working on a 32 by 8 Neo pixel trying to make it sound reactive with a spectrogram and make a great product progress and almost done. This week I'll be recording the first episode of The Bootloader with Todd Bodd. I ordered some new audio equipment for the podcast so it's like Christmas while I'm waiting for it. And unfortunately I will miss next Monday's meeting. Next up we have 2231 Puppy who is text only. Last week finished assembling my eFidget PCB and ran Circuit Python on it. This week work out the assorted hardware and software bugs in the eFidget. Next up is C Grover who is also is text only. C Grover submitted two community bundle libraries, Palette Fader which has been merged and DRV8830 motor controller driver which is waiting for review. Now that I'm having relatively good success navigating cookie cutter and pre-comment there are plans to submit more community bundle libraries starting with Range Slicer, a map range like class that incorporates input, yep not even going to try to say that word, hysteresis to reduce noise without filtering delays. Works nicely as a EuroRack CB quantizer but can be applied to other tasks like sensor and potentiometer noise reduction. I used it on a few projects to simulate rotary selection switches to reduce the size of the lawn by 50% to cut water consumption and waste. Trying to be proactive we don't have water issues in our area yet. It was suggested that I was just bored with the weekly mowing tasks. Next up we have Dan H. Okay, thanks. So I've been working on deep sleep current consumption and originally we were just trying to make deep sleep consume as little current as possible but in fact you might want to leave things on during deep sleep like power and I2C sensor that might give you a pin transition for instance to wake you up. So I'm adding an argument to the alarm.exit and deep sleep call which will allow you to preserve the current state of pins and hopefully that will work out and I have to do some more testing on that but it should allow kind of finer grain control over what's going on during deep sleep in terms of the pin state and there's still a lot of other things I'm working on for 8.0 fixing old bugs and new regressions that keep coming up because we get new issue reports all the time. Okay. Thanks Dan. Next up is DJ Devin 3. There we go. Last week I ironed out bugs in my flock box weather station post the link to that and this week I lost power twice this week due to lightning storms and the battery back it didn't skip a beat. There was no crashing due to no Wi-Fi or disconnection from open weather map so I put in some error handling that works great now. Let's see and I took Todd Botts 8 step Pico step sequencer and designed a 16 step sequencer that is obviously TR-808 inspired because it's 16. Designed a PCB based on that it took his board schematics from GitHub and a flurry of excitement hammered out a board designed in with two days with Red Bull then I set the board off to the fab no idea if it works so we'll see if it's going to smoke or not. I started on an RFM mailbox project that quickly turned into an encrypted RFM messenger based on the questions someone had about RFM and so that got me curious and I dove straight into RFM and encryption we're oddly enough and I already have a proof of concept working with fake chat streams like ping ponging back and forth and this is a really big undertaking because the RFM library by default does not have encryption baked in but yes you can send to different nodes where it will only pick up the node but the message itself is still in plain text so I'm working on a way to encrypt the plain text and then only send it to that directed node so it's not all open air if you want an encryption layer one will be available and that's all I got. Thanks cool project call me guy you're up next Alright thanks Bella I cookie-cuttered a new library up for the flip clock display I owe widget that I've been working on some work to expand on the examples I had kind of only the most basic proof of concept as an example with a bunch of older unused stuff in it still so it was cleaned up to show all of the actual basic functionality participated in the help desk over the past weekend and then for this coming week as well as earlier this morning I've been testing and reviewing some PRs including an interesting one that had me learning a bit about the RTTL spec which is ringtone transfer language I wasn't too up on that before but I've learned quite a bit about that this morning in order to test and review a PR there couple other things in the works this week are going to be adding some more documentation and cleaning up the flip clock library code as well as implementing a couple of options inside there that will allow you to use smaller sprite sheets if you want which I think will help it work on devices that don't have as much RAM as the feather TFT devices outside of the circuit python world for about the next month or so I'm teaching JavaScript courses on in the evenings a couple of nights a week so I will be less around in the evenings while I do that that's what I have for now thanks thank you that's very cool cat me you're up thanks paul so last week I worked on the wifi mailbox notifier guide the text content is for the most part in place the last thing to do is images I probably did other things but mostly I worked on the guide this week I need to get images for the mailbox guide and get it into moderation to be published that's done I will find out what's next and that's pretty much all I've got going on thanks cat me maker Melissa you're up next just a second I found it in the docs okay last week I finished up writing the web workflow code editor quick start guide and I wrote a bug fix for the core for folders being able to move inside themselves but needs a little rework on that I fixed a few bugs I found in the code editor while writing the guide I updated the loading animation of the spinning circular blinker I added a directory upload functionality to the code editor and I improved the dialogue layering a bit and this week I'm working on a code restructure I've been wanting to do for a while and I'm testing that and after that I'm going to be working on some features I have a little list to have and that's it thanks next up we have Mark gambler who is lurking last week he submitted a PR for the display shapes pie portal issue there's still a brightness setting issue but the slowdown is now gone thanks for the update tanny makes things you're up next thanks so last week we had the first circuit python community help desk event it went really well and there was lots of positive feedback there were some great conversation discussions in both the text and voice chats I really liked that we kind of left the format loose and we just had some really interesting conversation happening as well as circuit python stuff I also did a bit of hacking on the disco tool python tool that narrow doc wrote and I'm trying to make it so that when you do things which trigger circuit commands like installing and updating libraries that automatically runs a disco tool cleanup on mac os so that the extended attribute files that get generated with mac os writing to non mac file systems get removed because they can take up a ton of space on the device this week I'm hoping to finish that up and also see whether there's a way we can make circuit just not generate those files in the first place I don't know if there's something we can do with how it downloads the library bundles to prevent that problem but I want to do a little fiddling around with that and I'm trying to find a workaround for my OBS issue until the new version of mac os comes out of beta and that's what I've got thanks next up is tech trick who is text only last week created a new library for the Adafruit circuit python bundle a library for working with location beacons like iBeacons submitted a fix for adabot state of circuit python formatting and submitted a fix for the cookie cutter adding blank keywords to the pyproject.tomofile sometimes this week potential PRs for a cookie cutter update and adabot patch for instructions on installing optional dependencies defined in a repose optional requirements.txt file add more documentation to the core look at new libraries to create as well as potentially port to from Arduino and lastly additional typing PR reviews that was status updates next up we have in the weeds in the weeds is an opportunity for more long form discussions that either come out of status updates or that folks have identified ahead of time if you have any in the weeds topics please make sure they get added while we're discussing other things so this week tech trick tech trick added a great one which is what is the community planning to do around hectoberfest this year tech trick says he loved joining it last year and would love to help set things up if that's something we're interested in doing again this year I also had a response that too is we should probably start thinking about planning an October help desk event and maybe we could tie the two together comments do you want me to read off my response yes please sorry okay so we are absolutely doing hectoberfest this year and I would love nothing more than for someone else to help out with things adabot automatically applies the hectoberfest label to all the good first issues as hectoberfest begins and we typically see an influx of PRs so the biggest thing I need help with is keeping track of those PRs and putting in the work with the authors to get those PRs merged so basically in terms of what tech trick already does continue doing what you already do but maybe on a bigger scale for a short period of time does adabot add that label for like blink on libraries like that I'm not certain whether blink is included I know it does for the in fact I'm almost certain blink is not included I could be wrong though I would have to look I can totally check that out I know it does on the libraries that fall under the library section in the state of circuit python so all of those 130 good first issues would end up with the hectoberfest label and it's automatically removed when hectoberfest ends so but I will take a look and see if it snags blink a 2 basically it needs to be labeled good first issue and then it just gets added automatically yep sounds like there's interest in doing it it's just a matter of who's going to lead the effort and coordinate for sure and like I'm usually end up leading it and so bringing tech trick in would be super helpful and anybody else who wants to be involved who else wants to participate in hectoberfest probably must have just been circuit python dev channel or paying any one of us in the meeting as well that showed interest anything else for in the weeds this week alright we'll wrap it up this has been the circuit python weekly meeting for September 12, 2022 thank you to everyone who participated if you want to support Adafruit and circuit python those that work on circuit python consider purchasing from the adafruit shop at adafruit.com the video of this meeting will be released on youtube at youtube.com slash adafruit and the podcast will be available on major podcast services it will also be featured in the python for microcontrollers newsletter visit adafruitdaily.com to subscribe the next meeting will be held next Monday as usual at 2pm eastern 11am pacific the meeting is held on the adafruit discord which you can join by coming to adafru.it slash discord to be notified about the meeting and any changes to the time or day you can be asked to be added to the circuit python he says role on discord we hope to see you all next week thanks everybody thank you very much


Thank you for inviting me to speak to this important event tonight. I'm in London having last Tuesday attended John Pilger's funeral. It's been a great loss to Australia, to the United States, to Britain, and to the world. Since the US began its legal pursuit of drilling Assange, the world has changed dramatically, bringing new risks to the United States if it continues to pursue him to the end. The geostrategic situation and the state of the media are today nearly unrecognizable from 2010 when the US impaneled a grand jury to endide Assange. Conditions have changed significantly, even since 2019, when he was dragged from the embassy and the indictment was unveiled. The United States is in the midst of suffering its third major strategic defeat since the process against Assange began, bringing potentially significant consequences for the United States, the world, and possibly Assange. In just the past three years, the United States has experienced humiliating defeats in Afghanistan, Ukraine, and now Gaza. Afghanistan heard Americans sensitivities about their precious prestige, which American elites care so much about. The rest of the world takes it into its geostrategic calculations. The US instigation of war in Ukraine intended to weaken Russia and bring down its government has instead turned into a debacle for the United States and Europe of world historical proportions. A new commercial, financial, and diplomatic system has emerged in opposition to the US dominated West. This had been slowly developing, but was accelerated by Washington's provocation in Ukraine. It is a way more serious problem for the United States than mere loss of prestige. Add to this the worldwide condemnation the United States is facing for its blatant complicity in Israel's ongoing genocide in Gaza. It's in a war that both United States and Israel is not winning. The result of all this is that US legitimacy has significantly weakened around the world and at home. Is this the moment then to bring a journalist to the United States and chains to stand trial for publishing truthful material that exposed earlier crimes by the United States? The risks of doing so at this moment, a very different moment from 2010, are serious for the US at home and abroad. Domestically the bill of rights is at stake. Internationally the bully is losing its credibility. This is seen in the forthrightness of some world leaders, particularly in Latin America, who in the spirit of this new non-US world have confronted the United States on its treatment of Assange and have demanded his release. The established media, which by definition runs cover for the US to commit crimes and abuses wherever its interests are challenged, is suffering its own precipitous loss of legitimacy. The spectacular growth of both social and independent media's influence since 2010 has helped create a worldwide movement in defense of Assange and the basic principles of a free press. The question is, how aware is the Biden administration of this new world and how will it react? At a certain point, US hubris and intransigence would seem to be headed for collapse. But until then, Washington will no doubt double down in denial and inventions. It's not giving up on Ukraine nor in a Gaza. The neocon grip on power in Washington over the realists remains. Will the extremists remain ascendant on Assange too? In December 2010, Vice President Joe Biden told the television news show Meet the Press that the Obama administration could only indict Assange if they caught him red-handed stealing government secrets and not receiving them passively as a journalist. The Obama administration concluded he was acting as a journalist even if they refused to call him one and didn't indict him. So what changed for Biden? Why does he persist in this prosecution begun by his mortal enemy Donald Trump and Trump CIA director Mike Pompeo? The indictment until today still only deals with events in 2010. Nothing has changed legally, but everything has changed politically for President Biden, the head of the Democratic Party, with the 2016 DNC leaks and the CIA Vault 7 releases the following year. Biden would have held to pay from the DNC and the CIA if he dropped the case. Still, he's probably not so foolish to want a shackled journalist showing up on US shores to stand trial in the midst of his reelection campaign. The High Court here in London has been good at dragging things out and could easily do so until after November. The Assange case is thus a centerpiece of this global challenge to US dominance that did not exist in 2010. To the extent that US leaders are aware of what is happening to US standing in the world, their propensity is to lash out with the only argument they have left, lethal force. In Assange's case, it is legal force with lethal consequences. Leniency towards Assange would win back some respect the United States has lost, which would mean it couldn't suffer another blow and had finally woken to the new world it inhabits. Crushing him would be yet another step towards its demise. The US really doesn't need him. It has enough blood on its hands.


People They'll see that they'll see this okay Yeah, so I'll just pass it along and hopefully they can hear me. I can hear myself Okay, welcome back everybody on this beautiful day So we thought we would wrap up the meeting with a session that involves a kind of roundtable discussion Okay, from my point of view This is breaking up as I talk is that really happening? No, it's okay. Okay So we thought we'd wrap this up with a roundtable discussion and I've asked our panelists our distinguished panelists to spend a few minutes each answering one two or three of questions that we thought had had come up and the first was to Speak to themes that have emerged from this workshop that they think are worth You know what they found interesting found intriguing would like to highlight would like to identify as cross-cutting themes or important themes And the second is to if they found any themes that it didn't quite You know become really obvious themes from this things that may have been overlooked or things that may have been You know mentioned been passing but didn't come back around. I thought they could have mentioned some of that And then the third question is what are the next steps for this community for these two communities as we move forward? And so part of this is for us to hear from the panelists part of it is for us to have a discussion Among this entire community and part of it is to help inform the writing committee That's going to be preparing some sort of report document paper or for this community to go forward Okay, so without further ado, I will just pass the mic along. Can you everybody introduce yourself and then So my name is Yolanda van Wieck and I would like So I prepared a statement based on what I heard in some of the breakout groups that I thought that You may have an opinion about I want to Comment on So here it is so the two communities who are out two communities have been largely decoupled in the last decades Which has resorted into the parallel development of numerical modeling approaches So what we heard here a lot in the last two days were the problems that are still Very much alive in both modeling communities So the problems with the code so the codes are still very much in development So one could make a statement saying that this might not be the right time to start Coupling these codes and move for as a combined community However, because tectonics and surface processes are coupled at least some degree You could also say that code development in both communities should probably not continue to be parallel It should be continued to integrate And then I would like to quote one example of one of the breakout groups that I was in that illustrates What may have gone wrong in this parallel development of the codes So if you study the drainage system development and sediment infill of a rift basin People noted that it was found that for example the dip and depth of the border fault of a rift basin plus The shape of the hanging wall block of the rift basin Controlled to a large extent how your sedimentary basin fills up with sediments and how the drainage system develops So in geodynamic models as we just saw in John's talk The dip of a fault whether for this list trick what's depth it's actually roots Those are difficult to control results in geodynamic models But they matter very greatly in Service processes and landscape evolution. So in other words, it matters a lot in one community Maybe not reproduced well at the moment in the other community So the path forward could be more communication and collaboration between these communities. Maybe more Meetings such as this one and maybe something even like a community research initiative Should we break this up with question response or should we just each march through and give a statement any initial and initial thoughts on that Well, I just add to Yolante's that there's also then the step beyond beyond model group one and model group two You need it's in order for the yeah, you have to use it you have to really talk to it. Yep. Like a rock star Like the rock star you are I would just add that there's also the Observation Community at some point there that in perhaps compassed in this in the Surface processes modeling group, but you can't ignore So, thank you With the caveat that this is an impossible task to come up with a few seemingly intelligent things to say There's a few notes here. So one thing that came across very often in the breakout sessions and I think it's actually why we're here first place need for cross education Right so that each community needs to know well the other group. What do we know? What don't we know? Really like to know really like to be able to predict or what sensitivities we want to understand for our competition It's really essential you'll know what where's the common overlap? Problems that can be worked on the usually beneficial and Right, so I think we're kind of just getting to that point now Surface process either more from what the challenges in the tectonics models are So in a way, we're beginning to get ready to have that Conversation, but I guess one thing I'd like to add is I'd like to see the base Speaking of the data have the base and analysis community drawn into this group or Since many people have spoken to other sedimentary record is you a longer term Preservation of what the surface is Right back to even tens of millions of years. So that really should be part of this conversation And way if you think about at least in my mind the world of coupling surface processes and tectonics Way started the Chris Beaumont and his group circle other Peter Coons and his group were doing it sort of about the same time but for Chris Beaumont anyway came from a Idea of trying to understand that stratigraphic record. That's actually our It's our beginning. We probably should get back to it So one question that I feel like we May be partly because we're just beginning to complete the beginnings of that cross education Other than the breakout groups, we haven't talked that much about what do we want a couple models for? What are the question? What are we trying to accomplish? So where are the opportunities to gain new? understandings on on both sides, maybe there's some surface constraints really help nail down some parameters or uncertainties which approaches are best for the long-term tectonic models and vice versa and all of us of many have talked about difficulties of actually in both sides the surface process and the tectonic side you got a wide range of timescales Play a role or the server record And how do you manage that right even just the tectonic models? We're just hearing how do you manage? Model that maybe wants to be able to understand co-seismic displacements and longer-term mantle convection It's probably actually different models How do we tackle that anyway, we're having a conversation at dinner Thinking about what do you need one of any different categories of questions you might ask So we know that tectonics affects surface processes has an influence on So as we started off with a nice talk by Allison There are really good cases where you might want to use a tectonics model to drive a landscape I'll get better information how the surface responds. So in that case you want fully resolve landscape evolution Be able to take on board that Intensity of shaking or whatever it is pattern of up and pattern of substance On another class of questions Still uncertain whether surface processes really do influence tectonics like they're a two-way coupling A lot of us think so Most of our models predict that there would be so and it should be strong been hard to prove But in that case maybe the only things that matter for you can have a very simple surface process model because the effect on your Upper-crustal stress right, so maybe getting the mean topography right But great Tucker pointed out to me last night that Got to be careful because what if your observable data you want to use to test that model is At a higher resolution of data so that you need to know more details about that Apography or the sediments in the lake or whatever it is Depending on what data you're going to use to test those models might need more resolution or an intermediate class like the Dinas models looking at subduction zone Where the amount of sediment coming out in the nature of the sediment coming off might change the rheologic properties of all Rambling a little bit there but It's important to think about what the nature of the question. You want to ask a couple model help guide What's the perfect way to try to Classes so Guess only last thing just to one of the sort there are potential opportunities where surface observables help constrain Models say mantle dynamics one the ones that our communities talked about a fair bit Is the dynamic topography predicted by a man's infection models? Or different mental convection models predict completely different Histories of dynamic None some a lot very different timescales Those are surface observables that we could nail down say the up with history of the Colorado Plateau Might be able to start figuring out what are the Many of the good to think about What do we want a couple models for what are we trying to explain and where the opportunities? So does that mean the need is for collection of more data or for a synthesis of data that is already exists or for somehow consolidation of data and then ways to link it to the models Where there are new data sets that need to be collected well as a very general answer I would say that both fields are ultimately data limited can do all kinds of modeling you want but in the end That models got to be try to explain some data one of the biggest challenges Often there's a lot of uncertainty in that date like the case. I was just talking about that head new histories of Regional uplift that might be Attributed to dynamic topography mantle convection Then we could do something but most everywhere where that's hypothesized is great debate and great uncertainty of whether it up with it Or it's certainly landed up. Yeah, we need the data. We need the modeling capabilities to test against that data So I I'd like to start out with something that will never go out of fashion and not just specific to this field, but I good quality numerical methods and software so there are a lot of Opportunities there for improving the accuracy robustness numerical methods and for being able to use those methods and Software to formulate the inverse problems. And so one area that I think is relatively overlooked is Developing gradients of misfit functions with respect to parameters. So there's often spatially distributed parameters There's just a lot of parameters that we don't know and we choose them somehow we choose them based on some observations and some intuition but it Being able to take the gradient of some kind of misfit that says how well do we agree with data? That's something where there are good mathematical tools and we could write software in that way Sometimes it constrains the choices that we would make for numerical methods So if all we're doing is a forward prediction based on a known initial and boundary condition We have a lot of choices of methods and if we want to make a prediction whose derivative is not noisy then we have a subset of those Methods and so thinking more about formulating that inverse problem about developing our models and making them fit together in a way that I Can be used to solve those Inverse problems. I think that's definitely an important area Generally modularity of software the way that we go about Standing it to add new processes and The way that we exploit parallelism these are all important things that need to think about Looking particularly at how we compare with data So it's something that I think would be really useful is Software components that just provide misfit functions that just say how different are we from these Maybe very multimodal Sets of observations. So there are lots of different observation types If I make predictions from a tectonics model or from coupled tectonics and surface processes I'm gonna have lots of possible outputs that could be tested and the thing is In like no one person or no one research group has all of the expertise to go into all of those areas Find the appropriate data Figure out how to compare the predictions that we're making on the appropriate timescales I think that's something we can actually formulate into libraries and that would be really useful And so looking at coupled problems Right now the way that we tend to go about doing that is To generalize slightly surface processes people use laughably crude models of the tectonics and Tectonics people use laughably crude models of surface processes and sometimes we target problems that are like nearly overlapping But we use different methods and the way that we try to agree with data what the parameters that we're choosing to infer They may not be very physical because it's actually a coupled problem And so if we put that together we may get better solutions So we're asking about like where are the grand challenge problems where we really need coupled models And it may be these are problems that we're already working on But we're getting kind of non-physical solutions or we're having to over constrain our models We're specifying boundary conditions that aren't physical or we're specifying some parameters That aren't physical they allow us to fit some data, but you we're not really happy about and Ideally when we couple the models we would get out really physical states things that we Believe in and really justify so it maybe we don't need to look for new problems. We just need to Care more about the quality of our of our inference so there's a lot of questions in that area so I'm Really think the idea of having sort of standard components modular things to calculate Data misfits is a very useful and generalizable important step, and I think that A big piece of making that usable that I think we've sort of been dancing around but no one has really said specifically is that when you have Different types of data each Related to something you're trying to fit with your model figuring out how you combine those two things into Something that an inversion is dealing with is not necessarily trivial. So this would be different functionally defining weights and so That's sort of another piece another layer of thinking about the model data comparison and inversion that I Think would need to go along with Misfit component idea. Yeah, so one way of dealing with uncertainty there is if those Misfit functions were appropriately scaled then they could be combined Kind of without needing to do a lot of custom work It wouldn't be so application specific to combine these like multiple contributions towards a loss function But it's the uncertainty in the data that it needs to show up there and of course uncertainty From your model needs to come through as well Yeah, I guess my thought is I I think figuring out how to scale it right in a general way I would love to find out that it's easy Quick me if I'm wrong, but I think what you were getting at was Let's say we have two different constraints say we have a gravity field and we have up left field How do we wait? How do we decide which one is more important? Well, so I would say it should come from how accurate that measurement is and so if we have Really accurate Measurements, then we should try to agree very well with those Some observations can be really sensitive to the Molly running and the questions you're asking another Might get the right gravity field with any model But you'd write it might be another parameter. That's really sensitive to whether you've got the rheology, right or whatever Yeah, so actually I think when you talk about both in wasp program and also model uncertainty Which means you need to run at least a couple times of the model So I think before you're actually doing that you need to make sure you can run Couple like a hundred times the model first. I mean the computation source or or you can kind of simplify your model to do some kind of easy way to run the simulations Yeah, you definitely need the forward model to be reliable and fast in order to solve the inverse problems But there's no way around that Let me remind everybody in the room to please introduce yourselves including the panelists So that because there are people online who can't Yeah I'm Jed Brown I'm here at CU Boulder and my background is in computational science and I the second speaker Helen Wibble from Arizona State University So I'm Lee Rangoran. I'm from Ben Gorion University in Israel and So I actually I kind of so Louise told us that The discussion here should help the people writing the right paper tomorrow So in a way, I think the people that write the White paper are expecting maybe they expected this whole meeting to come up in a grand scientific challenge of questions And although we discussed them a lot. We haven't been able to name them. We didn't really identify them So maybe it's much harder than we expected to come up with these grand challenges And to stay the obvious Maybe we were not able to identify them because as long as we don't have highly detailed surface process and your dynamic models that are coupled Can all really identify all the possible coupling We are just imagining them or even we cannot even imagine them because they are unknown so maybe we first need to have Sufficient amount of such coupled models and simulations to identify these very special coupling or feedbacks and then we can find out So I would also like to maybe offer an imaginable such a feedback and this comes from a Pietro Sturney who's a postdoc in the University of Geneva. He actually asked me to tell you about that So so the Geodynamic Community has recently been able to identify an interesting feedback between climatic oscillations and magma production So I'm referring here to the glacial interglacial cycles that possibly control the volume of magma produced at mid-ocean ridges and Controls there for the topography of the oceans So maybe there are such interesting coupling that involves surface processes For example, if you have very intensive erosion then you can depressurize and Produce more magma and that can affect your climate and that can affect the efficiency of your surface processes So that might be a classical problem to address the highly detailed both surface process model and and tectonic model and Maybe and Louise also asked us to maybe suggest some Some goals can be New future or far future So I think that the the last session that we just had might point out that maybe a very near future goal could be to define an interface such that any Karen to future model from both communities Would like to fit this interface in terms of the input and output that it supplies and then When maybe you're slightly more mature More easily couple such models that were not intended initially Yeah, so I guess in a sense I agree. Oh, yes, my name is Sarah and I am a postdoc in Melbourne University So I agree that that may be That's why we haven't been able to formulate what the big challenges are because maybe we just have to I don't know Make a list of the 10 grand questions that we actually want address And then based on the questions, then we can figure out which models we need to come up with And I guess, you know, in a sense I would be kind of invoking the scientific method of like which questions do you have in a set of making the model This is Nicole Gasparini from Tulane University. So I'm gonna try and be half glass half full, which is very much not my normal personality But I feel like in this meeting We have had people who are really really super experts in Geodynamic modeling and surface process modeling and the most interesting thing For that surface process person is to like go to the things that we don't understand Distributions of floods and try to study it and like poke all the holes and everything that we know and try to find all these details Because that's super Exciting for us as a scientist, right? And so we've been maybe Motivated so much by our own individual kind of questions that we've focused on all of the unknowns in this meeting and Put forth sort of like here's all these warts that we have, right and all of our models are so bad And we need to know all these other things But on the flip side we get a lot of things right Right and so one question I have is like how perfect do we need to be before We start doing this coupling right because we're never gonna be perfect And so I sort of loved what you said which was Some of these questions might come forward when we start doing it because a lot of us have just been sitting in our own box Not doing it So we are not even focusing on those cool questions that are going to come out when we actually start the coupling So I think that's a really great way to think about it Sorry Germany was not fake. Sorry Now I just want to say a few things regarding the big scientific question Trying to address here maybe just To remind people that in many cases other models have actually Help answering or trying to answer the question that First instance, they're actually used to find the question I think it's something we shouldn't really not saying that shouldn't have a big question But you shouldn't make this pendant on big questions and I see also that a lot of Answers to be question will be question. We have discovered that the modeling I've come because we have coupled erosion models So, you know, my recommendation something we could do as two communities is Really work on the interface and and Through this give the opportunity To any member of one of the two communities to use the tools of the other community without having to Either reinvent the wheel or worry about how to And I really like Louie Mores's talk, which is a great Example of what this can be done This ends away Guys, you need MPI here is these are the guys have never done any MPI There's a way we can do and that it's broad enough It's not really specific one But I will also say that something really that I agree with telling them that one is to work We need also co-educate You know, I'm sure many of the geodynamic model is Really no ID different place your erosion and through your erosion and which Circumstances One would be more suitable than the other Down to using the simple So, I think that's anything I would like to see in the white paper But I think that's really essential Not just define questions It means to find I'm gonna go for it. All right, this is Eric Middlestead from University of Idaho. Sorry about the cold if I start coughing So So there's been a lot of things covered already. I'll do my best to add something new one of the themes that keeps coming up and has been Mentioned several times in this panel It was just brought up by Nicole in a different way is that The meeting of these two communities has caused a really interesting phenomenon Where the communities have looked at themselves and said, oh, you want to use what we use? Oh, well, we got to fix all this before I'll let you use it and I think that's a really important step And actually I think that's one of the most productive things to come out of this meeting is for us to reassess our own communities and and even down to our fundamental assumptions, so You know as Arthur pointed out in the talk earlier today is the viscous formulation Starting from the viscous formulation for long-term tectonics. Is that the right paradigm? Is the stream power model even the right way to go or should we do fully dynamic physics? You know these types of fundamental questions are really important But I also like what Nicole is bringing up and that when when are we good enough? When are we gonna start coupling and I think we should start Thinking about that and working together and and I think one of the ways forward and this is something that didn't come up very much except in passing Was what is this coupling? What is this coupling going to look like? What information? can long-term tectonic models give to surface process models and what information can surface process models feed back into tectonics So for example long-term tectonic models don't just give you uplift or don't just give you lateral motion They can give you information about stress and give you information about what lethologies are being exposed when They can give you information about damage So that's a lot more information than just uplift or lateral motion that can be incorporated into these surface process models I'm sure there's a lot more information that can go the other way I'd love to hear some people comment on that besides just how much material have we moved and where have we moved it but I think those kind of discussions before we go through the process of Coupling these codes are important Because we want to know what information we can use from each other's models And then that will help us hopefully answer more interesting questions So that's all I wanted to cover because a lot of other stuff has already been done So Paul Eitznerfer from the University of Pittsburgh. I'm a postdoc there and echoing Joan Browns and Comments on the grand challenge and also we are not giving you the model unless we fixed it That maybe one of the grand shares I'm wondering is can you provide the community with the tool That has been tested so that we can then Build up those research questions so that we feel conflict is that can you give it a coupled tool now? I'll test things like shall I now do a user stream power model and Let it work on the surface or any other model and then let's see maybe there is As a difference that I can actually measure. So what I would need is like I want to fix a car. I need my tool And the grand challenge can't be solved without the tool So I think one of the grand challenges is providing the community that tool Who is Carlos University of Mainz, Germany? One of the things so I Don't completely agree that there is the tool because as a matter of fact in the genomics community, we have seen many codes developed over the last I think we have made much more progress than I had thought possible Now we can do 3d multi physics problems They have learned a lot of lessons about that and the most important lesson is that we should not Should not force one code upon Let the different research groups do what they think We don't actually know the best way to to solve these equations And and that's why I think providing a framework that allows this and and takes common Features of all different codes that have been developed It's very useful thing to do and it turns out there are maybe like four or five now 3d parallel codes in the community And they all essentially are based on patsy as an underlying package And that is because patsy actually wrote we're very happy to have one of the main developers of patsy sitting in the middle here And thanks to that we have also learned that if you want to go into More complicated multi physics problems like couple magma migration with the sphere dynamics You cannot have a loose coupling on the top You cannot say okay I do one time step with the dark sea fluid flow And then I do one time step with the stokes codes and then I kind of iterate around and I hope that it will converge This doesn't work. What actually needs to be done is you need to do a tight coupling at the solver level Within the codes and within patsy there are now frameworks to do this very easily And so so one common thing is that actually patsy appears to work for big supporters The other thing is that many many people are now using more and more this kind of python frameworks and I think the best way forward in trying to provide this coupling is to to allow some kind of Framework based on patsy That allows you to kind of call one g-dynamic solver step with one particular code, which you could change and then couple it with a Surface processes framework also from within python that would work in parallel as well I think there has been a lot of progress and the development of this python tool that is very well supported And I think that make it feasible Providing one tool. I think it's the wrong But making sure that we can use and we have access to them that they explain They're talking about the interface that because some of us don't know how to code and they want to use their different parameters And maybe have a module setup, which is partly already done Here where we can use different modules and then model The way we think we can answer our question So, um, yeah, I very much agree with uh, liron and from round that It was a set of tools or one tool. I agree entirely It was more give us as many tools as possible but um, there should be some more validated and accessible in a in a way, let's say in a simple, let's say simple gui user example Or a nice manual because often receiving code and start reading a code for three months So understand the code. I think is uh, something that comes to the past and shouldn't be done in the future I think this is a Good idea. I think having these interfaces is great. And I think systems has certainly led the way here But I think one thing that we all need to keep in mind and this is something that's going to have to come from The community is if we want to do this as a joint community there's got to be some Talk with nsf or other funding agencies because we can't rely on some euro person To go out and use their research time to do this. So Um, I think this is a great idea and there's it's good to have discussion about this But at some point, you know, there's going to have to be some Some actual work into trying to get funding for this something some kind of systems type organization Maybe it could be called computational infrastructure for geodynamics or something similar to that In a way, right? I mean the these organizations these two organizations that are Here have been have a lot of experience. So actually we're in That's an optimistic statement that we can basically build on the infrastructure that we've already that we've built And that we've developed and the knowledge that we've learned about how to do it So I I'm actually very pleased to hear that suggestion because it's something we have learned how to do And have some experience doing you have some experience doing the csdms. So we have Basically the ability to do it. We have the capability of doing it We don't always have the capacity to do it at the scale that is being requested, right? So that's where the resources come in to To expand the capacity to do this That's kind of Okay, I'm gonna open it up. Oh wait, was there Sean gall in color out of state university Um, so I just want to change gears a little bit. Uh, there's been a lot of chatter about this. So how many people here Model and what data sets to obvious question. I hope it's how many people here collect data That you use to constrain how many of you know of Databases they're easily accessible what sets exist You can give a handful of examples of maybe some Osmogenic nucleide data sets maybe some areas where people compile thermo geometry, but one of the data sets that I collect a lot of is Paras is other metrics of deformation Frank was all you call Heliogiotis the heliogiotic market. So those exist for gps data. They don't A lot of these classical measurements Um, and if we had sort of a community effort By all those data sets So they could easily Accessible and could be used to inform the models that might be another way forward And I see that as sort of a grand challenge to try to standardize these data sets Not just publish them in the paper, but you get them out to the public so they can utilize in a really easy way Eitan Shelef University of Eitan Shelef University of Pittsburgh in So I think to add to the point in how perfect should our models be in order for us Find them and I think this ties to the issue of scale the discussions Perhaps a way to guide the questions with us Find the scale use this as a tool to hone on the questions you can answer I The modeling tools This is katie barnhart So one thing that came up last year at the csdms meeting related to coupling human systems models and surface processes and surface dynamics models Was that oftentimes um You know in an ideal world A person in one community is going to be able to have enough time or be able to find a collaborator or something like Be fortunate enough to find a user manual that is comprehensive enough They really understand the other model that they are connecting with but for a lot of really reasonable reasons that's not always possible and and so Oftentimes the thing you really want to know is you know, what can't I interpret about this other model What shouldn't I believe is true or what isn't necessarily? a feature that is A robust result And and one of the things we came up with in in a breakout session at csdms last year is, you know, we don't really have a way to incentivize uh people being really honest about that aspect of their models and that uh, that is often one of the most important things in figuring out how to Appropriately couple and then interpret the results of a coupled model, especially if maybe you only know one half of the coupling really well So, uh, I wanted to respond to Sean's point there So if I'm not in your field and I make some predictions with my model and it's coupled to some say surface process model that Where in principle it could be related to the field observations that you have the problem is I'm going to have to understand like your Field collection techniques. I'm going to have to understand spatial and oral correlation in your model I'm going to have to understand like how do we do upscaling with that sort of data and This is hard. This is actually like it takes a lot of intellectual effort to do that and so One thing you could do is along with your data. You could provide an uncertainty model Problem is that those uncertainty models are usually really high dimensional So a different way to represent it is to have it be like a posterior distribution So a distribution that I get to sample So I say here's my prediction and you tell me how probable that is so how close to your data is that And embedded in that In that function is How close did we get to the observations that you actually made? That's in fact what we need when we're trying to To solve an inference problem. So we're trying to understand Are all the parameters in our coupled model. We really just need to know how probable is it as compared to the observations And so That's basically my suggestion in terms of loss functions is Help us out make it so that we can actually put together these components Because if we're talking about a coupled model that has all kinds of surface processes plus tectonics This isn't like two or three areas. This is like at least 10 different kinds of data sources And it just isn't feasible for any one person or group to understand all of those things Can I add something in response to it? He just said about this so and a point that's come up in a couple places has having to do with Essentially making it possible for people to use models, especially in areas where they're less familiar And so I'll just lob a couple of ideas out there and see what resonates and one of them is that You know one way to do this is to have tutorials training essentially training and by training I mean really sort of pretty intensive, you know, maybe A few days of hands-on work one of our Software development teams has done this really well Highleth which is sort of short term crustal deformation scales Which they've offered both in-person and online training that lasts a week And it has Built in what they call tanker time Basically you start and you use learn to use the software to solve certain sort of standardized problems And you go away for a few hours In the afternoon or so on with the expectation You're going to keep working on it and then you come back and by that time you have some questions You're stuck, you know, you have things that you can't figure out The tutorial continues and uh the tanker time continues and so it's kind of this way of basically building building expertise Which as you can imagine takes a lot of dedication both from the people preparing the tutorial tutorials to make and delivering them But also from the people who are taking them, but it does result in a in a cohort of people who are More expert users than they were when they walked in the door, obviously the next level up often involves basically bringing Users and elevating them so that they become user developers where they're contributing something back To the software and not everybody wants to do that But some people do want to do that and they kind of opens the door to understanding what's Under the hood to continue the car repair metaphor uh, and essentially um allowing people to Even contribute back in a modest way still gives them kind of more of an investment In that software and so those are two things in terms of the quality of the Of software one of the exercises that we found has helped with that is uh, what we call benchmarking and usually this it's much more than Running a bench than a benchmark it often involves a group of people getting together defining Problems that they believe they understand the solution to and then Putting them out there to the world and having people run them on their software with guidance with Oversight so that we know what's being run and then getting them back together. That is a very big Uh dedicated effort. It can take several years From start to finish to get that done but it does give you kind of confidence in the models and also knowledge about the models and It's something that this group might want to think about what sorts of Benchmarks in the future. Would you like to see in terms of these couple problems? How would you go about defining it? What would even be the process of going about defining Attractable problems that could be done in this way. It's a long-term effort But it really does increase everybody's sort of understanding of what the models do and also confidence in the models And so I would really recommend it and then we also talk about Publication of software and how to publish it and how to treat it. This is part of this reward system Right how to treat it as an intellectual product because it is in the same way that a publication is an intellectual product We're used to the sort of academic publication sphere, but we are Trying to Push and there's a much actually much much larger scientific community trying to do this and information scientists and so on to try and push recognition of this sort of effort as an intellectual product making it both Publishable and then citable and that citability means that when the model uses something It says exactly what it did what is in the model What model version was used so what capabilities that has and that really helps with replicability of science Which is of course fundamental to the scientific enterprise So those are kind of i'm just throwing those out there as things to think about as you think about the next steps Whether you like any of those ideas or don't like whether you some of you might think well, that's too much work Some of them I think that's really essential to what we do. These are kind of ideas to consider as you move forward Oh, Rolf Alto University of Exeter and just One of the things I've really picked up from this meeting is learning a lot about Geodynamics that I wasn't previously aware And I was thinking it'd be very useful one one thing I'm trying to assemble in my head is a a list of things that Are fairly well known in geodynamics that I didn't know but Suddenly but also a list of key problems In geodynamics that may not be able to help it, but at least we know they're outstanding So just just having that kind of knowledge of capabilities and the outstanding questions particularly in so far As they interface with the surface in a way that someday One of the things that I found very interesting was the problem of scale In that seeing all these excellent talks from Geodynamics Very large problems Are being increasingly sliced Into higher higher resolution using all kinds of new options for parallelism to to really decrease that resolution to a spatial scale That is something that we At the earth's surface and similarly seeing how some of the earth's surface models are scaling up to larger problems So other than that kind of list of the key outstanding questions Hopefully addressed by the other maybe just an idea of where key scales Spatially We must help each other Does anybody want to reflect on that or not? If not, I'm gonna ask or you're gonna Present a question Okay, so here's the question from online from Lorraine And she asked asks is there a straw horse grant challenge problem that will illustrate what we know What is not known And what our capabilities are Either To the front or or to anybody in the audience Well, I mean my my comment was sort of along similar lines and I I wanted to come back what you mentioned earlier That the aces is where it all started and and to me some of the some of the issues that have come up over and over are sort of about Validating and examining the cascade of natural deport, right? We sort of want to understand Does our general understanding of plate tectonics and continental dynamics allow us to predict the sediment boxes right now? That's really important for planetary evolution for the carbon cycle. We want to understand say for You know for for continent like Africa. Do we get the overall transport? Like zooming in we got major originic belts of the zenozoic You know the Andes and Tibet and then you know sort of going down in scale You know people have of course done this for centuries trying to understand transports surface transfer processes all these different scales, but I think It would be somehow useful to to just sort of rally around this concept that we need to understand these different laboratories to to check, you know, what are the scales where which algorithm applies the scales have to capture And what is sort of ringing in the back of my head is of course, how are we how are we going to get You know money for this and of course one extent it's sourced to sink, right? This is to lie about it. The all industry is interested in the same sort of stuff But that is an opportunity and then of course we have things like the integrated earth systems program Which is just about that but as a geodynamicist always feel like IES as a program expects this fully formed model Whereas we are just talking about well, how should we come and somehow when you get involved in these projects? You always get stuck never get it done, right? And so I feel like as the service process models and geodynamicist if we could somehow get Get a more coherent strategy going to have these is kind of collaborative things be driven by examining these systems And be serious about the model right to not have as much I've experienced this right. Oh, we didn't get funded. Let's ask a geodynamicist next time I want to get funded and then no one really cares, right? But I think there is an opportunity here to think about the overall transport budgets Like you said, right on the basin scale and what's happening like in this mountain with the basin scale and on a global scale All right, if you want to get an atmospheric evolution on planets things like that Think about cascades of validation exercises natural report Alison Anders, University of Illinois So one thing I was really struck by in this meeting is that unlike the climate erosion tectonics coupling that we were talking about back when I was in grad school where Apography was the only Connection, I think we are starting to think more about other ways that they might connect And I think the example that really struck me as one that might be a place where There are gains on both sides is about fracture spacing or damage or something like that, which is increasingly being thought about in the surface processes and critical zone communities as being driven by topographic stresses, but also by the tectonic history of things and then this seems like this is quite involved in strain localization and And similar problems from the geodynamic standpoint. So My eyes are really opened about how there's something else that might be a way that That the talking happens But also that maybe these some of these outstanding problems Are not actually so disparate. I mean, is this is really a problem about how The properties of the material change as they move through the system toward the surface and then In transport on the surface. It's really more of a continuum thing than Splitting everything into the surface and the subsurface So that I don't know that struck me as like a new problem. Perhaps all of you have thought of that already before but that was new to me If I could just respond to that it's actually a really nice opportunity for possible, you know mutual interest and joint benefits one of the Big unknowns this was mentioned. I think in Brian's talk, especially How does that erosion efficiency? end on material properties We need what we need a lot more data. We probably need some theoretical thinking we ought to work how how do we make that connection make the robust measurements of the trail properties translate them to erodeability essentially Because we're going to need that to know how that fracturing Exactly in that context um, it also matters these kind of interface properties like uh, putonic activity that changes the mountain range And that's something that right now. Maybe nobody really feels like they hold What strikes me is a lot of people saying I didn't know that you knew this and I didn't know that this was an Open scientific question. I think that's really very interesting so that's Already a benefit I would say Are there other thoughts that add to this like people are running out of steam? Are there other thoughts from the panel? We identify grand challenge questions or big questions or at least think about how That would that would be a major contribution i'm karah johnson University of Nevada, you know, I'm postdoc and I have a question for you. What's the we've been hearing a lot about big mental convection Plates subducting what's the small scale of the modeling that you guys do how how fine do you get how far are we from this idea of modeling fracture spacing or Stuff at the scale that a river might interact with or or surface processes Let's take that out I may not offer a complete answer, but I mean the smallest models we saw in the talks were a single fault So that's a common scale that people look at You know, it's just about scaling the size of your model if you wanted to look at Joint spacing in a hundred meter by hundred meter by 10 meter area You could set up that problem Now there's going to be comments on that, but it's the same mechanical equations are also added on the nanometer scale So as long as you can resolve the grain scale or whatever you can use the same approach to model planetary accretion you can model Behavior of crystals and acorniability as long as the physics doesn't change if you go to the earthquake cycle Things are very fast and you need to start adding Also, that's But of course, I cannot address that and at the same time model the whole Yeah, that's fair to opt in from GNS in New Zealand basically Say what Boris said, but we can definitely you choose your scale to a certain extent based on your problem and they're you know, so We can model the alpine fault of New Zealand at several different scales But it's just what processes are you looking at and what question you're trying to answer and we can take say A plate scale model take the boundary conditions from that And and scale them down to a much smaller model so that we can look at the valley scale or you know The fault zone on on sub kilometer scale Yes, so just to add to that. It's this question about, you know, the continuum approximation So the stuff we do We assume that the micro physical processes And the micro physical heterogeneities can be averaged over on some meaningful scale and some some point that's going to break Some point you're going to run into we don't want to deal with dislocation motions if we have a business people But if you really want to zoom in then at some point You're going to have to be open material ahead of genetic that you may or may not know So it's a question of averaging when this come it's come up over and over again With this informal way Organization approaches and course Or you can try to find approximate descriptions I think a lot of it hinges on the validity of these Approximations and when they break down you have to be really careful that you're not Stretching the parameters space and moving beyond the range of where those conversations Okay, so we are coming to the end of our time and that was a very interesting and lively discussion I appreciate everybody's input I'd suggest we thank the panel