Font awesome

Add --glyphs to use fontawesome glyphs instead of letters as markers.
For now, I think the results are rather ugly. but Jinja2 makes it reasonably easy to fix if we want.
Rob, if you want to play around, and see if there are better glyphs to use, look at lines 91-96 of templates/log_analysis.html.  This is where the letters and glyphs are set.

There was a spurious ; on line 95 of log_analysis.html that was preventing the download icon from showing.

I think there must be a bug with the gallery icon. Consider this session:
<IP_ADDRESS> (0:30:38) / 2018 Dec 31 16:39:28 (0:05:42)
There are multiple viewings of the gallery, but there's no icon. Is it possible you're only displaying the icon with view table?

I like the search, gallery, and zip download icons. I think they are intuitive.
The columns icon makes me think they are looking at a table, which we don't have any way to distinguish going forward. But I can't find a better icon.
Likewise I'm not crazy about the X-circle for old slugs, but I can't find a better icon.
I think the icons would look better with just slightly more horizontal spacing.

Line 95

Fixed
On Tue, Feb 12, 2019 at 4:01 PM Robert French<EMAIL_ADDRESS>wrote:

I think there must be a bug with the gallery icon. Consider this session:

The column glyph and the gallery glyph were swapped.  It was telling you
that the user had viewed the gallery, but incorrectly!

I like the search, gallery, and zip download icons. I think they are
intuitive.

Okay.  Do you want me to get rid of the letters and only use glyphs?  I was
never actually intending that --glyphs be an option.  Just a way for you to
compare outputs.

The columns icon makes me think they are looking at a table, which we
don't have any way to distinguish going forward. But I can't find a better
icon.

Yeah.  I know.

Likewise I'm not crazy about the X-circle for old slugs, but I can't find
a better icon.

book-dead?  biohazard?

I think the icons would look better with just slightly more horizontal
spacing.

If I do this, I'm also going to make the left-hand column a little bit
wider.  Maybe 33% instead of 25%.
I'm not sure I know the html magic to give a little bit more horizontal
spacing.

p.s.  I'm really glad that I switched to jinja2.  It let's you write code
that more closely resembles real Python.  It also lets you pull out common
code into a single place, and even just makes the code easier to read by
being able to refactor it into smaller routines.
It's only disadvantage seems to be that it generates more whitespace, and
there doesn't seem to be an easy way of telling it to remove it.  My
On Tue, Feb 12, 2019 at 4:56 PM Frank Yellin<EMAIL_ADDRESS>wrote:

I like the search, gallery, and zip download icons. I think they are
intuitive.

Okay.  Do you want me to get rid of the letters and only use glyphs?  I
was never actually intending that --glyphs be an option.  Just a way for
you to compare outputs.

The columns icon makes me think they are looking at a table, which we
don't have any way to distinguish going forward. But I can't find a better
icon.

Yeah.  I know.

Likewise I'm not crazy about the X-circle for old slugs, but I can't find
a better icon.

book-dead?  biohazard?

I think the icons would look better with just slightly more horizontal
spacing.

If I do this, I'm also going to make the left-hand column a little bit
wider.  Maybe 33% instead of 25%.
I'm not sure I know the html magic to give a little bit more horizontal
spacing.


Addition of non_quantized flag to enable non-quantised encoding for L…

…DM training on the VQVAE.

Done @marksgraham


Chef Metal with 1.0

Dear Team,
When Chef Metal will be come out with 1.0 version for Production ready. From versioning, its looks it is in Beta. So is it really in beta or ready for Production use?

Hey @uchit66 - chef metal was renamed to chef provisioning.  The core chef-provisioning software is 1.0 and ready for production use, but there are still issues and bugs that we are actively tracking down and closing.  I would highly suggest using it in a test environment first and making sure these bugs do not affect you, or wait until they are fixed to use it in production.
The specific drivers (like chef-provisioning-aws and chef-provisioning-vagrant) have their own versions.  Generally, anything that is greater than 1.0 is production ready (it has a supported API) but again, it may have active bugs that we are working on.
TL;DR - use it in a test environment first.  But we do have people successfully using it in production.


Discord SDK download returns 403

Hi,
I just started using this but quite quickly ran in to an issue, when I try to download the SDK from the discord servers it returns a 403, So I was wondering if I'm doing something wrong, there is a problem with the libary or there is a problem with discord.
I'm just using the example code for dowloading the SDK.

This is caused by Discord (or Cloudflare) trying to block automated requests.
They seem to block the User-Agent sent by some Java versions, but allow some others.
You could try to set the User-Agent to a common value (e.g. a Firefox version) to avoid this problem.
URL downloadUrl = new URL("https://dl-game-sdk.discordapp.net/2.5.6/discord_game_sdk.zip");

URLConnection connection = downloadUrl.openConnection();
connection.setRequestProperty("User-Agent", "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:<IP_ADDRESS>) Gecko/20100316 Firefox/3.6.2");

ZipInputStream zin = new ZipInputStream(connection.getInputStream());

(see https://github.com/JnCrMx/MinecraftDiscordLobbies/blob/1.16.4/src/main/java/com/github/JnCrMx/discordlobbies/DiscordLobbiesMod.java#L60 for an example)

that seems to do the trick, thanks!


v16/schemas/StopTransaction.json missing "Hertz"

In issue https://github.com/mobilityhouse/ocpp/issues/71 "Hertz" was added as valid unit. However it should also be allowed within StopTransaction's transactionData.

After checking the referred document "OCPP 1.6 Errata sheet, v4.0 Release, 2019-10-23, on page 33" I think that change done in https://github.com/mobilityhouse/ocpp/issues/71 might be incorrect. The document doesn't specify that unit "Hertz" should be explicitly defined and allowed in schema. Latest official ocpp 1.6 schemas for Metervalues.json and StopTransaction.json don't have "Hertz" as enumeration for "unit".
Document: OCPP 1.6 Errata sheet, v4.0 Release, 2019-10-23, on page 33:
OCPP 1.6 does not have a UnitOfMeasure for frequency, the UnitOfMeasure for any SampledValue with measurand: Frequency is Hertz.
The question is that should change https://github.com/mobilityhouse/ocpp/issues/71 (https://github.com/mobilityhouse/ocpp/commit/22306f06962ab61448ef0c54d09e92318675fccf) be actually reverted?

Good catch. I think you're right and Hertz has not been added as a Unit. However, reverting the change would be backwards incompatible.

Would it still be better to fix (i.e. revert) instead of keeping incorrect enum and schema there? Now it's possible to send non-standard MeterValues messages.

I think you're right. Given that we're currently before a 1.x.x. release, this package can have backwards incompatible changes according to SemVer. I'll revert the change soon.

Satisfied with PR https://github.com/mobilityhouse/ocpp/pull/497 - will be included in next major release

Referenced in https://github.com/mobilityhouse/ocpp/issues/174


Typo in documentation for Defining a Two-Stage Fallback rule

Need an update in the documentation of Rasa Open Source (here)

In the above code snap the step of a rule is set with active_loop: two_stage_fallback, but there is no default action naming two_stage_fallback

Hey,
I would like to contribute to fixing these issues!
Can I get assigned for this?

Thanks for raising this issue, @melindaloubser1 will get back to you about it soon✨
Please also check out the docs and the forum in case your issue was raised there too 🤗

Hey  @prathameshThakur thanks for pointing this out! You're right, it should be action_two_stage_fallback. Feel free to open a PR to fix it and tag me in it.

Hey @melindaloubser1, I have made a pull request.
Can you please review it!


missing reference_data.sql

I'm trying to set up dataverse-k8s for development for the first time and find it fails with:
-bash-4.2$ skaffold run -p init -p payara
Generating tags...
 - iqss/dataverse-k8s -> iqss/dataverse-k8s:v4.19-63-g413cd89-dirty
 - iqss/solr-k8s -> iqss/solr-k8s:v4.19-63-g413cd89
Checking cache...
 - iqss/dataverse-k8s: Error checking cache.
failed to build: getting hash for artifact "iqss/dataverse-k8s": getting dependencies for "iqss/dataverse-k8s": file pattern [dataverse/scripts/database/reference_data.sql] must match at least one file

I think this was because I didn't sync submodules.

I think this was because I didn't sync submodules.

Glad it worked out for you!

Glad it worked out for you!


Lint/EmptyBlock should not apply to empty lamdas

It is often useful to have an empty lambda as a callable placeholder (for instance to stub out a callable or as an initial value in dynamic function composition. Lint/EmptyBlock flags these, but there isn't really a better way to express these (-> { nil } is not better here IMO). This should apply to both lambda and ->.

Expected behavior
Rubycop should not register any offenses about this code:
expect(Foo).to receive(:callable).and_return(-> {})

Actual behavior
Rubocop registers an offense.
Offenses:

spec/test_spec.rb:1:46: W: Lint/EmptyBlock: Empty block detected.
expect(Foo).to receive(:callable).and_return(-> {})
                                             ^^^^^

RuboCop version
1.2.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.1.1, running on ruby 2.6.2 x86_64-darwin18)
  - rubocop-performance 1.8.1
  - rubocop-rails 2.8.1
  - rubocop-rspec 2.0.0

Is there any reason to ignore empty lambdas but register offenses for empty procs (i.e. Proc.new {} or proc {})?
The usage as a placeholder is very similar to the mentioned for lambdas, but when arguments must be ignored.

@gPrado makes sense, can you make a new issue?


Replace variadic with exact where appropriate

Closes #868

The only custom functions I keep as variadic are rand and rand_integer because rand doesn't necessarily need an input and rand_integer doesn't necessarily need 2 inputs, as demonstrated here: https://github.com/dask-contrib/dask-sql/blob/e104cc5e0e85e3cce9dff5dd2d445bbebb723521/tests/integration/test_rex.py#L164

Codecov Report

Merging #885 (60ac31d) into main (e9ff9cd) will decrease coverage by 2.15%.
The diff coverage is n/a.

:exclamation: Current head 60ac31d differs from pull request most recent head ca918b3. Consider uploading reports for the commit ca918b3 to get more accurate results

@@            Coverage Diff             @@
##             main     #885      +/-   ##
==========================================
- Coverage   77.48%   75.33%   -2.16%
==========================================
  Files          71       72       +1
  Lines        3607     3779     +172
  Branches      635      674      +39
==========================================
+ Hits         2795     2847      +52
- Misses        685      795     +110
- Partials      127      137      +10

Impacted Files
Coverage Δ

dask_sql/physical/rel/custom/create_model.py
88.70% <0.00%> (-2.82%)
:arrow_down:

dask_sql/physical/rel/custom/create_experiment.py
96.15% <0.00%> (-0.10%)
:arrow_down:

dask_sql/physical/rel/custom/wrappers.py
28.07% <0.00%> (ø)

dask_sql/_version.py
35.31% <0.00%> (+1.41%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


| Fail | Invalid SDK version: unexpected character '\r' after patch version number

After attempting to create a new mod (after running geode sdk update), I get the following results:

will fix asap, dont know why cli doesnt trim the version

fixed in v2.4.2

Thanks, will update

Works now 👍🏾


Groups in Auth

Right now, ACLs can only contain individual GitHub accounts. This is, at the very least, annoying when trying to add the same users to several repos over and over.
For 1.7, we'll add a simple API: ModifyGroup(GroupName, toAdd, toRemove), and ListMembers(groupName). We'll also need to extend SetScope(Principal) and ModifyAdmins(to_add, to_remove) so that they can accept groups. Until 1.7, we simply ask users to pass strings to these calls with the prefix group (so that adding X to an ACL isn't ambiguous when there's a group named X and a GitHub user named X). We might add a structured representation of Principals before 1.7 if needed

(note that, as with ACLs, there's no difference between an empty group and a group that doesn't exist)

Per https://github.com/pachyderm/pachyderm/issues/2432, we'll also have a few default magic groups, such as group:all, which implicitly includes all signed-in users

to clarify scope: are groups a flat namespace, or can i add a group to another group?

Still relevant, just didn't make it into 1.7
On Wed, Feb 14, 2018 at 9:32 AM, stale[bot]<EMAIL_ADDRESS>wrote:

This issue has been automatically marked as stale because it has not had
any recent activity. It will be closed if no further activity occurs. Thank
you for your contributions.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pachyderm/pachyderm/issues/2433#issuecomment-365684003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABtjwMUyd24n0XOOS5TWv8hbQ3T5Aztpks5tUxingaJpZM4P_8-B
.


Migrate reportback data

What's this PR do?

added a function to transform what a phoenix status is to a rogue status
added script to migrate reportback data to phoenix

How should this be reviewed?
👀
Any background context you want to provide?
I still have a few todos/checks

Once in rogue, does this retry sending back to phoenix? Can we disable that?
If the script fails and we need to re-migrate all info, the call to dosomething_rogue_store_rogue_references will fail because it doesn't check for duplicate rows

Relevant tickets
Refs #7225
Checklist

[ ] Documentation added for new features/changed endpoints.
[ ] Tested on staging.
[ ] Pinged a PM if this is a larger PR that would benefit from some additional testing love
[ ] Post a message in #phoenix if this includes something that causes a rebuild!

🎉


allow to custom region-split-check-diff

Signed-off-by: qupeng<EMAIL_ADDRESS>What problem does this PR solve?
Issue Number: close https://github.com/tikv/tikv/issues/9327.
What is changed and how it works?
Related changes
Check List
Tests

Unit test

Side effects
Release note

No release note.

/merge

/merge

/lgtm

/lgtm

/merge

/merge


create https s3 module and apply it to cardigan

Type
🚑 Health
This will make it safer to deploy things.
@kenoir @alexwlchan any use for the https_3s_website?

Merging as the terraform is applied. Happy to run through it.


Shared Image Gallery Destination Version Variable not passing through

Note
Issues in this repo are for tracking bugs, feature requests and questions for the tasks in this repo
For a list:
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks
If you have an issue or request for the Azure Pipelines service, use developer community instead:
https://developercommunity.visualstudio.com/spaces/21/index.html )
Required Information
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Type: Bug
Enter Task Name: here
list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks
Environment

Server - Azure Pipelines or TFS on-premises? Azure Pipelines

If using TFS on-premises, provide the version:

If using Azure Pipelines, provide the account name, team project name, build definition name/build number:

https://dev.azure.com/apolinarorg2/ContainerRegistryPush/_build

Agent - Hosted or Private:

If using Hosted agent, provide agent queue name:

If using private agent, provide the OS of the machine running the agent and the agent version: Mac Catalina

Issue Description
[Include task name(s), screenshots and any other relevant details]
When using the Packer Task, I am not able to pass the Managed Image Version. The variables never makes it into the Packer File. For example, if I pass in a variable from the pipeline that sets this value: "image_version": "{{user build_version}}", it never makes it to the packer image. If I run this locally on my machine, it works perfectly fine.
"shared_image_gallery_destination": {
"resource_group": "{{user managed_image_resource_group_name}}",
"gallery_name": "GalleryName",
"image_name": "CentOS7",
"image_version": "{{user build_version}}",
"replication_regions": ["eastus2"]
},
Task logs
[Enable debug logging and please provide the zip file containing all the logs for a speedy resolution]
Troubleshooting
Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting
Error logs
[Insert error from the logs here for a quick overview]

Any news regarding this issue?


Configurate Merge adds keys

Description
This PR changes the merge_config function to allow new keys to be create and values set during the merging process.
Testing

[ ] Remove current .config/king-phisher/config.json file.
[ ] On the login window right click and import configuration file, that has keys not set on default load, example key ssh_server
[ ] Login and then then close King Phisher
[ ] Cat out `~/.config/king-phisher/config.json' to verify import was successful

Instead of removing the whitelisting of keys, why not add the key names to the config file that non-existent keys are loaded from when the application starts up?


OpenBLAS gets available cpu using _SC_NPROCESSORS_CONF

Hey All, we are recently shifting our numpy-based workload from VMs to Containers. We noticed that the open blas use the following code to get the available cpus for linux.
  if (!nums) nums = sysconf(_SC_NPROCESSORS_CONF);

This will read the all cpus of the host, rather than the online cpus that, for instance, LXCFS might inject for container isolation.
We currently use some env like OPENBLAS_NUM_THREADS to explicitly set the number of thread, but is it possible to change the code to read the online cpus like using sysconf(_SC_NPROCESSORS_ONLN)?

the obvious drawback of _SC_NPROCESSORS_ONLN is that it isn't useful on systems where cpus are brought online by the os in response to demand, which is why this code was changed to use the _CONF value

the obvious drawback of _SC_NPROCESSORS_ONLN is that it isn't useful on systems where cpus are brought online by the os in response to demand, which is why this code was changed to use the _CONF value

Sorry, I might not quite understand what you refer to.
You mean the os might bring more cpus online, while the program is running and by using _SC_NPROCESSORS_CONF can handle this situation?
I thought it's highly unlikely to occur (please correct me if I'm mistaken, but it has never occurred in our cases). However, in a containerized environment, using _SC_NPROCESSORS_CONF will result in a thread pool size that is too large, potentially leading to significant context switch costs.

see #981 - it might be possible to make that behaviour architecture- and/or OS-dependent, but there will probably be some overlap with container use on those platforms we single out too. The other question that comes to mind is whether your containerized environment should expose the global _SC_NPROCESSORS_CONF to the container at all, rather than the limited subset assigned to it.

many thanks for mentioning those issues, We might optimize our containerized environment by modifying the  _SC_NPROCESSORS_CONF as you suggest.


Fix colors in the app to be accessible to colorblind people.

Fix colors in the app to be accessible to colorblind people using the Bang Wong palette.

instruction and buttons

prediction polygon

prediction hexagons

annotation

new colors look so much better!


"best", rank uses fping

Rank now uses fping for faster parallel pinging (pacman -S fping)
Added best command. Supports regions, filters the servers by load and then orders by ping.

relevant: https://github.com/nstinus/nordvpn/issues/11

Thank you for your submission. It is a substantial change. I'll have more time to look at it this week end but one thing that you'll need is to update the documentation as well.

Added documentation and keyword filtering

I reviewed attentively your contribution and I thank you as it is quite valuable.
I have however a couple of remarks.
I took the liberty of editing the commits as to break them up. Here are the reasons for doing so:

some had different features combined so I split them;
dev in one commit, doc, possible typo fix after.

In general, don't commit things that are not related together; it'll make the review much easier as the maintainer can keep some and reject others. Look at git rebase -i for more info.
Couple of issues, open questions:

Doc is not exhaustive: at least your best command is not mentioned in the synopsis.
the maxload/ping combination does not seem right to me. With a default maxload=30, my best server is usually with a ping >40ms; I guess I don't really care about the load as long as the ping is good. Perhaps we should get some info from openvpn as I regularly connect to pretty loaded servers and everything is fine for me.

I created a branch in the main repo (pr25). Please review it, address my remarks above and I'll be happy to merge it.

Sure, I'll rebase to split features into additional commits.
When looking for a low-ping server where the load is irrelevant, maxload=100 could be passed. This, however, pings all the servers in the region and takes more time.
I guess it all depends on which is required at the time: a relatively high-bandwidth (e.g. for netflix and the like) or low ping (e.g. for browsing / chat / ssh). This PR was originally meant to provide a way to find a suitable server for the first use-case.

Ok I see what you did in your branch.
Only one comment:
For me, the + at the end of the lines (and removing empty lines from the synopsis) does what you wanted in the FIXME.
Another idea:
The default maxload should be removed. Instead, an option to filter by maxping should be added. Also sortping and sortload should be added. This would facilitate looking for all combinations of ping/load.

Regarding the manpage line breaks, I created a new ticket #31 as it seems it needs to be investigated a bit. Please weigh in there as on my end the + does not work.
I guess maxload is fine, it is just that the default value should be way higher. I am also open for other parameters but we should keep things simple. It is good that people can customize it; but in my opinion, for the general case, it should just work without having to mess around to much.

I'll close this in favor of the new PR based on your branch


[Do Not Merge] Enable one-way closure parameters by default.

Experiment with enabling one-way closure parameters by default.

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

How to change the base branch: (Link)
More detail about the branch update: (Link)


chore: bump provider version

Description

Release required?

[ ] No release
[x] Patch release (x.x.X)
[ ] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[ ] If relevant, a test for the change is included or updated with this PR.
[ ] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

:tada: This PR is included in version 4.11.7 :tada:
The release is available on:

GitHub release
v4.11.7

Your semantic-release bot :package::rocket:


Not able to update object on PARSE when it added from iOS platform

I have tried to update Parse object from Parse CloudCode function. I want to update status_id for one particular entry whose objectId is "vZveFx3KcP”. Whenever i call following function no entry gets updated. but whenever i added manual entry or entry from Android device it gets updated without any issue. For iOS i am using latest Parse version "1.11.0". I got this issue only to those entries who gets added by iOS platfrom.
Can any one Please explain where i am going wrong. I am new to javascript programming so let me know if you need additional information from me. You can check my code below. I have tried calling cloud function from Parse API console.
Parse.Cloud.define("freshFunction", function(request, response) {
       var GameScore = Parse.Object.extend("Booking");
       var query = new Parse.Query(GameScore);
       query.equalTo("objectId", "vZveFx3KcP");
       query.first({
                  success: function(results) {

                  alert("Successfully retrieved " + results.length + "user_id");

                  results.set("status_id", 2);
                  results.save();
                  response.success();
                  },
                  error: function(error) {
                  alert("Error: " + error.code + " " + error.message);
                   response.error();
                  }
                  });

       });

I am updating these entries from cloud code. I am able to fetch and update those entries from iOS platform. But those entries are not updating when we call them from cloud code. In cloud code i am getting success message but in reality its not at all updated. This happens to entries who are added from iOS platform. For android and manual entry function works fine.
Can anyone face the same issue ? Let me know if you need additional info from me. I have also added this issue on Parse iOS SDK Github. https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/issues/723#issuecomment-169077787
Thanks in Advance,
Akshay Aher.

The issue is probably due to the fact the save() is an asynchronous process -- when you call response.success(), the outstanding request to save the object is immediately cancelled. You need to wait until the save succeeds before you can respond.


add playground link

@nhooyr https://github.com/terrastruct/src/pull/1878

did you setup notifications to discord by adding the necessary secrets?

can u say more about that? i think you mentioned before but i can't find instructions

Slacked


Remove monofile-utilities dependency

Reorganize external utilities and add internal utilities file
Add internal noop function

Fixes #46

Codecov Report

Merging #59 (c30f4e4) into master (0646965) will increase coverage by 0.14%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##           master      #59      +/-   ##
==========================================
+ Coverage   65.00%   65.14%   +0.14%
==========================================
  Files          10       11       +1
  Lines         240      241       +1
  Branches       73       73
==========================================
+ Hits          156      157       +1
  Misses         75       75
  Partials        9        9

Impacted Files
Coverage Δ

src/sync.ts
0.00% <0.00%> (ø)

src/utils/index.ts
27.02% <ø> (ø)

src/async.ts
84.84% <100.00%> (ø)

src/utils/internal.ts
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0646965...c30f4e4. Read the comment docs.


how to visualize the ply format point cloud

Thank you for your great work!
I am new to MVS area, I find it is hard for meshlab to open such large a ply file, is there some other way to visualize point cloud smoothly?

Thank you for your great work! I am new to MVS area, I find it is hard for meshlab to open such large a ply file, is there some other way to visualize point cloud smoothly?

Please refer to CloudCompare.

thank you


Config layout refactor: centralize config file for documentation

What changed?

Why?

After this configuration, we will have all config defined in the same package, so that our documentation can simply link a place<EMAIL_ADDRESS>

packages of auth + authorization are confusing.

Remove the gocql.Client from configuration to make it more client, and avoid cyclular dependency

How did you test it?
existing test

Potential risks

Release notes

Documentation Changes
Will update cadence-docs after this change is released: https://github.com/uber/cadence-docs/pull/32

Pull Request Test Coverage Report for Build b7c01585-77c8-48f4-b4dd-6269a96a5652

50 of 124 (40.32%)  changed or added relevant lines in 17 files are covered.
10652 unchanged lines in 19 files lost coverage.
Overall coverage decreased (-7.2%) to 59.749%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

common/persistence/nosql/nosqlplugin/cassandra/gocql/client.go
6
8
75.0%

common/persistence/nosql/nosqlplugin/cassandra/gocql/public/testBase.go
0
2
0.0%

tools/cli/adminCommands.go
0
3
0.0%

tools/cassandra/main.go
1
5
20.0%

common/messaging/kafka/clientImpl.go
1
7
14.29%

tools/cassandra/cqlclient.go
9
22
40.91%

common/persistence/nosql/nosqlplugin/cassandra/gocql/public/client.go
9
27
33.33%

tools/cassandra/handler.go
3
29
10.34%

Files with Coverage Reduction
New Missed Lines
%

common/task/weightedRoundRobinTaskScheduler.go
2
89.64%

service/history/handler.go
2
46.59%

common/cache/lru.go
3
90.73%

common/types/history.go
4
24.69%

service/history/historyEngine.go
4
70.81%

service/history/queue/processor_base.go
7
61.82%

tools/cli/factory.go
9
12.24%

tools/cassandra/cqlclient.go
46
41.22%

tools/cassandra/handler.go
49
13.18%

tools/cassandra/main.go
113
3.91%

Totals

Change from base Build 85851b48-9518-4c44-a5a3-ba37840f3c73:
-7.2%

Covered Lines:
87724

Relevant Lines:
146822

💛  - Coveralls


[v9] Issue with radio and Version Status

Issue
When selecting version status as a filter for the advanced page search the version status radio options are stuck absolute to the left of the dialog. This is due to the parent div or its class .radio not having position relative.
Possible Solution
One solution would be to add the class .radio to the bedrock repository with the correct formatting. However other radios in the video, do not use the radio class and instead use .form-check. So we could replace any instance of .radio with .form-check however the HTML is different for these.
See below HTML for differences between the two, tidied up for readability.
Html
// the .form-check html

    <input type="radio" id="cParentAll1" name="cParentAll" value="0" class="form-check-input" checked="checked">
    No

// the .radio html

        <input type="radio" id="versionToRetrieve3" name="versionToRetrieve" value="2" class="form-check-input">
        All

Video or screenshot
https://user-images.githubusercontent.com/23059797/116188330-34d5ea00-a762-11eb-9eac-ae8435ce2c6f.mov

we should just fix the markup to conform to bootstrap, by adding form-check html. We've already done this in the ParentPageField.php class, we just need to do it here as well.


Ruby: Fix creds import for LRO Client

Codecov Report

Merging #1665 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@             Coverage Diff              @@
##             master    #1665      +/-   ##
============================================
+ Coverage     85.53%   85.53%   +<.01%
- Complexity     4286     4287       +1
============================================
  Files           405      405
  Lines         16842    16844       +2
  Branches       1762     1763       +1
============================================
+ Hits          14405    14407       +2
  Misses         1849     1849
  Partials        588      588

Impacted Files
Coverage Δ
Complexity Δ

...transformer/ruby/RubyImportSectionTransformer.java
98.7% <100%> (+0.03%)
24 <0> (+1)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a461d99...9e505a0. Read the comment docs.

New commit PTAL.

@landrito Can this be merged?

Bah! Yep will merge shortly.


Add link to video tutorial in README.md

Pull request checklist:

[x] CHANGELOG.md was updated, if applicable

Description
Hello. This is my first ever Pull Request.

This adds a link to a video tutorial on YouTube that I created that shows how to download and install Chatterino Nightly on Windows, as long as the regular version of Chatterino is already installed.

Fork has been deleted, let me know if you want this re-opened.


Likelihhod error in num_outputs > 1 in toy_regression when batch_size >1

When I try to extend to num_outputs > 1 based on the toy_regression script

No problem when num_outputs >1 with batch_size =1.
But, when batch_size>1, I debug the problem is in likelihood(y_pred)

y_pred = MultitaskMultivariateNormal(loc: torch.Size([4])) -- batch size is 2, nums_outputs is 2
Current run is terminating due to exception: Shapes are not broadcastable for mul operation.
Engine run is terminating due to exception: Shapes are not broadcastable for mul operation.
RuntimeError: Shapes are not broadcastable for mul operation

if you can modify toy regression script to support num_outputs>1, I will be very very appreciated!
Thanks ahead!

I would like to give a more detailed example:

1D to 1D, batch size =2, it is ok even the batch size is whatever, plz see the y format, it is a 1D tensor list.
batch = [tensor([[-5.6533],[ 5.5243]]), tensor([ 0.5068, -3.5898])]
x in batch = tensor([[-5.6533],[ 5.5243]])
y in batch = tensor([ 0.5068, -3.5898])

-1D to 2D, batch size = 1, it is ok. Plz see the y is a 2D list.
batch = [tensor([[13.]]), tensor([[13., 14.]])]
x in batch = tensor([[13.]])
y in batch = tensor([[13., 14.]])
-1D to 2D, batch size = 2, error occurs.
batch = [tensor([[10.],[ 4.]]), tensor([[10., 11.],[ 4.,  5.]])]
x in batch = tensor([[10.],[ 4.]])
y in batch = tensor([[10., 11.],[ 4.,  5.]])
I also print the y_pred, y_mean and error message:
y_pred = MultivariateNormal(loc: torch.Size([2]))
y mean = tensor([0.0004, 0.0005], grad_fn=)
loss =  tensor([80.9260, 16.0182], grad_fn=)
Current run is terminating due to exception: grad can be implicitly created only for scalar outputs.
Engine run is terminating due to exception: grad can be implicitly created only for scalar outputs.
I have checked the classfication scirpt, the output is still 1D (the predicted class in the 10 classes). So I can not figure out how to extend toy_regression script.
Could you give me some guidance? Thanks!

Can I ask one more question about the format of x and y in toy regression script?

Why is return x[..., None], y, not return x[..., None], y[...,None]?

I recommend you check the documentation of GPyTorch, they will have an example for this!

Thanks for your reply, I think I find the solution.
Change Gaussianlikihood to MultitaskGaussianlikelihood.


enter text code

@keybase/react-hackers
Do 'already on keybase? login'
Connect another device
Phone
Type text code instead

@keybase/react-hackers  bump

:thumbsup: %C


[Dynamic Regions] tikv oom after Inject one tikv network_partition last for 50m and recover due to lack of flow control for log replication

Bug Report

What version of TiKV are you using?
./tikv-server -V
TiKV
Release Version:   6.7.0-alpha
Edition:           Community
Git Commit Hash:   c3e1cfb04046fe8ee1bc4a7ce453f273490e697a
Git Commit Branch: heads/refs/tags/v6.7.0-alpha
UTC Build Time:    2023-03-14 11:42:04
Rust Version:      rustc 1.67.0-nightly (96ddd32c4 2022-11-14)
Enable Features:   pprof-fp jemalloc mem-profiling portable sse test-engine-kv-rocksdb test-engine-raft-raft-engine cloud-aws cloud-gcp cloud-azure
Profile:           dist_release
2023-03-15T01:10:09.762+0800	INFO	k8s/client.go:132	it should be noted that a long-running command will not be interrupted even the use case has ended. For more information, please refer to https://github.com/pingcap/test-infra/discussions/129
What operating system and CPU are you using?
8c/32g
Steps to reproduce
https://tcms.pingcap.net/dashboard/executions/plan/1657727
ha-tikv-random-to-all-network-partition-last-for-50m
http://perf.pingcap.net:3000/d/WOw1JWmVk/ha-test-case-detail?orgId=1&refresh=10s&var-case_id=2820443
What did you expect?
tikv should not be oom
What did happened?
tikv oom after Inject one tikv network_partition last for 50m and recover

clinic: https://clinic.pingcap.com.cn/portal/#/orgs/31/clusters/7210433082137609367?from=1678813797&to=1678819847

/feature developing
/severity major
/assign busyjay


Add PATCH to normalized method names

Discovered in https://github.com/facebook/react-native/issues/4594, PATCH is not included in the normalized method names. This lead to some problems with the lowercased patch being forwarded onto the OkHTTP library in React Native and throwing an error as it was not interpreted properly.
This adds consistency to the method name normalizing process by including all the supported/common method types.

Unfortunately, the spec doesn't include PATCH in the set of normalized methods.
You'll just always have to write out PATCH in uppercase until this is changed in the fetch spec.

Interesting, alrighty then.

After reading through https://github.com/whatwg/fetch/issues/50 on this very issue, normalization is only a convenience method to help support old code. The TL;DR of it is, just write verbs in the correct way, uppercase.
I guess where some of the disconnect and confusion here is that all the examples in this are in lowercase, if they were to be presented in uppercase and the normalization hidden, then there would be less confusion.
So, would it be appropriate to update all examples so that their method names are in uppercase?

@Lavoaster That's a good idea. Consistency in this would help people avoid the patch trap.

I'm wondering what @dgraham's thoughts on this are, I've just seen #272 which was rejected not too long ago.

Patch needs to be treated as a first-class method, with normalization, in the fetch specification to solve this problem. Shouting verbs into a readme feels like progress because we control that file, but until patch is treated humanely, we'll continue to spend time debugging this inconsistency in method handling.
/cc https://github.com/github/fetch/pull/272#issuecomment-177602462

The guy(s?) working on the spec for fetch, from my interpretation, doesn't see it that way. If you read through the issue I linked above they mention that normalization is, strictly speaking, breaking http standards as methods are case-sensitive and that normalization was only added for backwards compatibility - This was even noted in the spec here after a previous request (in 2014) to add PATCH to the normalization verbs was declined. The issue also talks about it not being normalized because it would be a breaking change for people relying on the case sensitivity for patch.
You hope for a future that I personally don't see forthcoming. You argue on relying on normalization which only exists for backwards compatibility, you also argue to further be non compliant with the HTTP standard which defines method names as case sensitive by relying on a "fix" for non-compliant applications, and finally the future you're arguing for is a specification that will need to be patched every time a new verb is added. You say this is inconsistent, but this inconsistency has been caused by people not following the HTTP spec correctly in the first place, and yet you're here arguing to further that inconsistency rather than correct it.
I get that this isn't an issue for those who want to be spec compliant, but by not being spec compliant yourself, you're pushing people into this trap because your examples are being used as a reference for the rest of the internet on how to use fetch, as this package is what allows its use today. Examples in the fetch spec use uppercase method names, and for that matter all references to method names are in uppercase in the spec, The MDN article on fetch uses uppercase method names.
This won't solve entirely solve the problem of normalization, but it will improve the situation.

@dgraham I'm not prepared to let this issue just fade away. If you're insistent on not changing the examples here and hiding normalization, then why haven't you logged an issue to change the spec?

@dgraham , do you agree that the current README is setting developers up to waste time debugging this issue? If so, there are steps you can take today to help alleviate or even eliminate that problem (the one of wasted developer time) altogether.
Keeping the verbs lowercase in the README without mention of how they actually should be (and in some cases need to be uppercase) is creating this new problem. And it's doing nothing to help fix the spec that you believe should be changed.
I think there are ways to update the README that communicates your opinions while also being pragmatic. Consider:

A Note on Verbs
The examples in the README use lowercase HTTP verbs. Although it'd be nice if we
could use lowercase all of the time, the spec writers disagree with me on that point. For
other verbs, like PATCH, you'll need to be sure to use uppercase letters.

Although it'd be nice, you can't will the spec to change by rebelling against uppercase verbs in the README. The only consequence of this action is wasting the :clock1130: of lots of people.

Current README examples do give the reader the impression that HTTP method can be supplied in lowercase. I can totally understand how somebody would be surprised that patch isn't included in this normalization. I'm 👍 on accepting a PR that uppercases our examples, unless @dgraham thinks that effort would be futile.
But please, don't get too worked up on this issue. Even though a subset of developers might get bitten at some point, the situation isn't that dire.

FYI - There is now an issue to add console warnings whenever normalization is invoked. https://github.com/whatwg/fetch/issues/259


Image Caching is not working.

Hello, I run this app on iPhone, it seems that image caching is not worked, as I see that if I force-close the app and reopen it, then images were reloading but not fetch from cache.

Hi! Yep, that is by design. Image cache is not persisted within app launches.


Cache crashed, failed to delete file

I'm starting to see a lot of this exception in my app released with OkHttp 3.01 via Picasso 2.5.2 (using Jake's adapter from 3.01 to 2.5.2)
Fatal Exception: java.lang.RuntimeException: java.io.IOException: failed to delete /storage/emulated/0/Android/data/com.trixiesoft.clapp/cache/images/51d313bf28724ba47541b0ca45ac084f.0
at okhttp3.internal.DiskLruCache$1.run(DiskLruCache.java:178)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)
Caused by java.io.IOException: failed to delete /storage/emulated/0/Android/data/com.trixiesoft.clapp/cache/images/51d313bf28724ba47541b0ca45ac084f.0
at okhttp3.internal.io.FileSystem$1.delete(FileSystem.java:70)
at okhttp3.internal.DiskLruCache.removeEntry(DiskLruCache.java:599)
at okhttp3.internal.DiskLruCache.trimToSize(DiskLruCache.java:656)
at okhttp3.internal.DiskLruCache.access$200(DiskLruCache.java:85)
at okhttp3.internal.DiskLruCache$1.run(DiskLruCache.java:172)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:841)

@KennyGoers do you happen to have any other information? Can you reproduce with a simple example or test case?

It's the best I can do for this one, it comes up in my crashlytics crashes.
I'll see if I can find some device correlation, but if I remember it was
scattered across 4 and 5 and different manufacturers.
On Mon, Feb 15, 2016, 7:22 AM Dave Roberge<EMAIL_ADDRESS>wrote:

@KennyGoers https://github.com/KennyGoers do you happen to have any
other information? Can you reproduce with a simple example or test case?
—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-184205494.

@KennyGoers the disk cache implementation should now recover from this scenario, see #2366.
Thanks!
On Thu, Feb 25, 2016, 3:24 PM Dave Roberge<EMAIL_ADDRESS>wrote:

@KennyGoers https://github.com/KennyGoers the disk cache implementation
should now recover from this scenario, see #2366
https://github.com/square/okhttp/pull/2366. Hopefully you won't see
this exception again :)
—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-188994682.

We do not provide release ETAs because OkHttp is not a product.
On Thu, Feb 25, 2016, 7:09 PM Kenny Goers<EMAIL_ADDRESS>wrote:

Awesome, time line on release!
Thanks!
On Thu, Feb 25, 2016, 3:24 PM Dave Roberge<EMAIL_ADDRESS>wrote:

@KennyGoers https://github.com/KennyGoers the disk cache
implementation
should now recover from this scenario, see #2366
https://github.com/square/okhttp/pull/2366. Hopefully you won't see
this exception again :)
—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-188994682.

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-189046594.

NP, just wondering if anything might be pushing one like the 3.1.2
situation. I can build my own.
Thanks for taking the time.
Your work is much appreciated.
On Thu, Feb 25, 2016, 6:15 PM Jake Wharton<EMAIL_ADDRESS>wrote:

We do not provide release ETAs because OkHttp is not a product.
On Thu, Feb 25, 2016, 7:09 PM Kenny Goers<EMAIL_ADDRESS>wrote:

Awesome, time line on release!
Thanks!
On Thu, Feb 25, 2016, 3:24 PM Dave Roberge<EMAIL_ADDRESS>wrote:

@KennyGoers https://github.com/KennyGoers the disk cache
implementation
should now recover from this scenario, see #2366
https://github.com/square/okhttp/pull/2366. Hopefully you won't see
this exception again :)
—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-188994682.

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-189046594.

—
Reply to this email directly or view it on GitHub
https://github.com/square/okhttp/issues/2318#issuecomment-189047941.

No ETAs. But Actual time of arrival of 3.2.0 is right now.

Closed with #2366.

@swankjesse so is this in 3.2 or 3.3?  You say 3.2, Milestone says 3.3.  So confoosed.

3.2.


Immutable schema model

Having spent the last few days hacking on Swashbuckle, I was wondering whether or not anybody had floated the idea of refactoring or deprecating the current schema models in favor of immutable ones?
The mutability and lack of deep copying functionality makes things like caching inline or primitive type schemas a non-starter. It could also allow for more robust validation at construction time.

Tell me more.... we are going to have to do some non-trivial changes in OpenAPI 3.1 because the way we handle JSON Schema is changing a lot for 3.1.
Can you show what kind of inline caching you would like to do?

@MaggieKimani1 Could you confirm that the schemas created by JSONSchema.NET  are immutable?

@jcracknell the JSON schema object exposed by the JsonSchema.Net library is completely immutable; you can't directly add or update its keywords/properties. You can however use the JsonSchemaBuilder object to build inline schemas. You can find more information in their docs here https://docs.json-everything.net/schema/basics/


The order in which object properties are defined -  effects  on query key.

Describe the bug
Based on your documentation -  order of properties in object no matter. But in my case - the order in which object properties are defined -  effects  on query key.
Your minimal, reproducible example
Full describe in reproduse section
Steps to reproduce
In both example below - same query with same params called in two separate components, but at the same time.
Some definition which used in our code & below
const appsInventoryRetrieveKeys: unknown[] = ['apps', 'inventory', 'retrieve'];
const entityId = '090515e2-a03a-465d-8301-9d663e64360b';

app.fingerprintID.app === 'd99ac760-0ad6-11ea-9b04-c7455c63d59e'

Example when it working correctly:

Define entity id

const id = new ItemID();
        id.app = app.fingerprintID.app;
        id.id = entityId;

Use it like queryKeys

appsInventoryRetrieveKeys.concat(id)

Repeat steps 1 & 3. in other component

Result

Query hash from query dev tools
queryHash: "[\"apps\",\"inventory\",\"retrieve\",{\"_app\":\"d99ac760-0ad6-11ea-9b04-c7455c63d59e\",\"_id\":\"090515e2-a03a-465d-8301-9d663e64360b\"}]"

In this case all works well but :
Example when works wrong:

Define entity id

const id = new ItemID();
        id.app = app.fingerprintID.app;
        id.id = entityId;

Use it like queryKeys

appsInventoryRetrieveKeys.concat(id)

Define entity id  in other component , but properties in other order.

const id = new ItemID();
        id.id = entityId;   // just switch it order
        id.app = app.fingerprintID.app;  // just switch it order

Use it like queryKeys

appsInventoryRetrieveKeys.concat(id)

Result
In this case we already have 2 different queries , with different query hash

queryHash: "[\"apps\",\"inventory\",\"retrieve\",{\"_app\":\"d99ac760-0ad6-11ea-9b04-c7455c63d59e\",\"_id\":\"6fef6f95-feee-4653-a4e9-57866c921a12\"}]"

queryHash: "[\"apps\",\"inventory\",\"retrieve\",{\"_id\":\"6fef6f95-feee-4653-a4e9-57866c921a12\",\"_app\":\"d99ac760-0ad6-11ea-9b04-c7455c63d59e\"}]"

Expected behavior
I expect that order of setting object properties - does not change ready query hash (query key)
How often does this bug happen?
Every time
Screenshots or Videos
No response
Platform

OS: MacOs 12.5.1
Chrome: Version 106.0.5249.103 (Official Build) (x86_64)

react-query version
4.7.2
TypeScript version
4.8.4
Additional context
"@tanstack/query-core": "^4.7.2",
"@tanstack/react-query": "^4.7.2",
"@tanstack/react-query-devtools": "^4.7.2",
"typescript": "^4.8.4",

you still need to show a codesandbox reproduction please, because I'm not going to put that code in a runnable environment to debug it. That's your job.
FYI, here is our default hashing function:
https://github.com/TanStack/query/blob/f9ebf9aaae59050331c22f143d835e46fac402cc/packages/query-core/src/utils.ts#L269-L280
it's a json stringify where all plain objects are sorted. My best guess is that your ItemID class (?) is not an json serializable object, but again, you're not showing that, so how should I know. Pretty sure this works:
const id = {}
id.app = app.fingerprintID.app;
id.id = entityId;

🤷
if you use special stuff like classes as keys, you'd need to provide your own queryKeyHashFn.

Sorry if i was incomprehensible , this my first experience of opening issue.
I missed  queryKeyHashFn option in docs.  So i use it in config for cover all call(api & hooks) :
const config = {
  defaultOptions: {
    queries: {
      refetchOnWindowFocus: false,
      retry: false,
      queryKeyHashFn: (queryKey: QueryKey): string => {
	...

const queryClient = new QueryClient(config);

This works as i expecting, thanks


Labels

Need to add label files in a separate folder.

This issue is getting closed with reference to this 77bf6e3 commit.


Need  help regarding customfields in weeb hook

Hi ,
My need to  add the custom fields like  two text fields and i will pass value to api it  should be hidden in the signer view,but it should be visible to the webhhook
kindly how to implement in php

Metadata can be stored at the envelope level by usi g custom envelope fields. See https://stackoverflow.com/a/67779223/64904

yeah, that's example 16, as shown here.
...
      # Create the salary field. It should be human readable, so
        # add a comma before the thousands number, a currency indicator, etc.
        $salary_readable = '$' . number_format($salary);
        $text_salary = new Text([
            'anchor_string' => '/salary/', 'anchor_units' => 'pixels',
            'anchor_y_offset' => '-9', 'anchor_x_offset' => '5',
            'font' => "helvetica", 'font_size' => "size11",
            'bold' => 'true', 'value' => $salary_readable,
            'locked' => 'true', # mark the field as readonly
            'tab_id' => 'salary', 'tab_label' => 'Salary'
        ]);

        # Add the tabs model (including the sign_here tab) to the signer
        # The Tabs object wants arrays of the different field/tab types
        $signer->settabs(new Tabs(
            ['sign_here_tabs' => [$sign_here],
            'text_tabs' => [$text_legal, $text_familiar, $text_salary]]));

        # Create an envelope custom field to save the "real" (numeric)
        # version of the salary
        $salary_custom_field = new TextCustomField([
            'name' => 'salary',
            'required' => 'false',
            'show' => 'true', # Yes, include in the CoC
            'value' => $salary]);
        $custom_fields = new CustomFields([
            'text_custom_fields' => [$salary_custom_field]]);

        # Next, create the top level envelope definition and populate it.
        $envelope_definition = new EnvelopeDefinition([
            'email_subject' => "Please sign this document sent from the PHP SDK",
            'documents' => [$document],
            # The Recipients object wants arrays for each recipient type
            'recipients' => new Recipients(['signers' => [$signer]]),
            'status' => "sent", # requests that the envelope be created and sent.
            'custom_fields' => $custom_fields
        ]);

        return $envelope_definition;
    }
...


Is it possible to draw a line from static element to the cursor position?

First of all, I'd like to give big thanks to @anseki  for this library. It's really well done and is helping my project immensely.  Thank you :+1: :smiley:
Now, I'd like to ask if the following is possible with leader-line:
On mouse down on target element draw a line from the clicked element to cursor's position, the line should be redrawn to and when the cursor is moved. The line would disappear once the user releases the mouse button.
I need this for a tool I'm building where users can connect elements with lines, and I would like to mimic  functionality of Visio where you can drag and pull the line to the target element.

Hi @rokmesojedec, thank you for the comment. :smile:
Does this example help you?
https://anseki.github.io/leader-line/#startsocket-endsocket
If you want to draw a line from the element to mouse pointer that no-element is there, you can do that by using pointAnchor. That allows a line to be positioned anywhere in the document.
Or, you might use a transparent element.

The draggable example did the trick! Thanks a lot.


Stratified plane Couette flow test

We agreed that stratified plane Couette flow could be a test case against which we can verify the implementation of AMD in PR #309, although the published results [Vreugdenhil & Taylor (2018)] use a slightly modified version of AMD.
They report a number of LES runs, and since we don't have a vertically stretched grid, it might be easiest to try and reproduce the Pr = 0.7 case which they do with (Nx, Ny, Nz) = (64, 49, 64) grid points [for Ri=0 or 0.01, for Ri = 0.04 it's (64, 65, 64)]. I might suggest focusing on the Ri = 0 case as they also run a resolved DNS with (Nx, Ny, Nz) = (256, 129, 256) against which we might be able to compare (might not be possible, depending on vertical grid stretching).
Unfortunately, I don't think we can reproduce their results without a vertically stretched grid... If I understand the paper correctly, the grid is stretched according to
y_j = h*tanh(Sf*(2*(j-1)/(Ny-1))) / tanh(Sf)

so for h=1 you get grid spacings of Δy ~ 0.125 away from the wall and Δy ~ 0.0000035 adjacent to the wall. So a faithful reproduction would need 285,000+ vertical levels lol.
I don't fully understand how they got their values for the vertical grid cell size adjacent to the wall ∆y_w^+, but it seems like if h = 100,000 then our values agree (they get a spacing of Δy ~ 0.35 adjacent to the wall). Either way, the ratio between the thickest and thinnest spacings is ~35,000.
Not sure if there's still a way we could compare results in this case without a vertically stretched grid...
Absolute worst case scenario, I've been working on an implementation of a vertically stretched grid (see PRs #283 and #306) but it's a work in progress and might not be the best use of our efforts right now.
Reference: Catherine A. Vreugdenhil and John R. Taylor, Large-eddy simulations of stratified plane Couette flow using the anisotropic minimum-dissipation model, Physics of Fluids 30, 085104 (2018).
cc @glwagner @rafferrari

Hi all,
Greg, do you know if Cat Vreugdenhi is visiting GFD this summer? It may be easy to ask her to run an example without stretched grid. That said, do we have a good sense of how important a stretched grid is for the accuracy of our LES simulations?
Raffaele

On Jul 10, 2019, at 9:32 AM, Ali Ramadhan<EMAIL_ADDRESS>wrote:
We agreed this could be a test case against which we can verify the implementation of AMD in PR #309, although the published results use a slightly modified version of AMD.
They report a number of LES runs, and since we don't have a vertically stretched grid, it might be easiest to try and reproduce the Pr = 0.7 case which they do with (Nx, Ny, Nz) = (64, 49, 64) grid points [for Ri=0 or 0.01, for Ri = 0.04 it's (64, 65, 64)]. I might suggest focusing on the Ri = 0 case as they also run a resolved DNS with (Nx, Ny, Nz) = (256, 129, 256) against which we might be able to compare (might not be possible, depending on vertical grid stretching).
Unfortunately, I don't think we can reproduce their results without a vertically stretched grid... If I understand the paper correctly, the grid is stretched according to
y_j = htanh(Sf(2*(j-1)/(Ny-1))) / tanh(Sf)
so for h=1 you get grid spacings of Δy ~ 0.125 away from the wall and Δy ~ 0.0000035 adjacent to the wall. So a faithful reproduction would need 35000+ vertical levels lol.
I don't fully understand how they got their values for the vertical grid cell size adjacent to the wall ∆y_w^+, but it seems like if h = 100,000 then our values agree (they get a spacing of Δy ~ 0.35 adjacent to the wall). Either way, the ratio between the thickest and thinnest spacings is ~35,000.
Not sure if there's still a way we could compare results in this case without a vertically stretched grid...
Absolute worst case scenario, I've been working on an implementation of a vertically stretched grid (see PRs #283 and #306) but it's a work in progress and might not be the best use of our efforts right now.
Reference: Catherine A. Vreugdenhil and John R. Taylor, Large-eddy simulations of stratified plane Couette flow using the anisotropic minimum-dissipation model, Physics of Fluids 30, 085104 (2018).
cc @glwagner @rafferrari
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Alternatively, we can compare with the original database of stratified plane Couette flow DNS runs by Deusebio et al. (2015) who varied Re and Ri, and Zhou et al. (2017) who varied Pr and Ri.
That way we can design our own experiment, but maybe we still can't do anything rigorous without high-resolution near the walls.
Maybe we could increase the vertical resolution and see if our solutions (the statistics) converge towards the resolved DNS solution?
References:

Enrico Deusebio, C. P. Caulfield, and J. R. Taylor, The intermittency boundary in stratified plane Couette flow, Journal of Fluid Mechanics 781, pp. 298-329 (2015).
Qi Zhou, John R. Taylor, and C. P. Caulfield, Self-similar mixing in stratified plane Couette flow for varying Prandtl number, Journal of Fluid Mechanics 820, pp. 86-120 (2017).

Ali, i thought the stretching was sorted now, after the hackathon. Without
stretching the code will have limited use. John
On Wed, Jul 10, 2019, 3:32 PM Ali Ramadhan<EMAIL_ADDRESS>wrote:

We agreed this could be a test case against which we can verify the
implementation of AMD in PR #309
https://github.com/climate-machine/Oceananigans.jl/pull/309, although
the published results use a slightly modified version of AMD.
They report a number of LES runs, and since we don't have a vertically
stretched grid, it might be easiest to try and reproduce the Pr = 0.7 case
which they do with (Nx, Ny, Nz) = (64, 49, 64) grid points [for Ri=0 or
0.01, for Ri = 0.04 it's (64, 65, 64)]. I might suggest focusing on the Ri
= 0 case as they also run a resolved DNS with (Nx, Ny, Nz) = (256, 129,
256) against which we might be able to compare (might not be possible,
depending on vertical grid stretching).
Unfortunately, I don't think we can reproduce their results without a
vertically stretched grid... If I understand the paper correctly, the grid
is stretched according to
y_j = htanh(Sf(2*(j-1)/(Ny-1))) / tanh(Sf)
so for h=1 you get grid spacings of Δy ~ 0.125 away from the wall and Δy ~
0.0000035 adjacent to the wall. So a faithful reproduction would need
35000+ vertical levels lol.
I don't fully understand how they got their values for the vertical grid
cell size adjacent to the wall ∆y_w^+, but it seems like if h = 100,000
then our values agree (they get a spacing of Δy ~ 0.35 adjacent to the
wall). Either way, the ratio between the thickest and thinnest spacings is
~35,000.
Not sure if there's still a way we could compare results in this case
without a vertically stretched grid...
Absolute worst case scenario, I've been working on an implementation of a
vertically stretched grid (see PRs #283
https://github.com/climate-machine/Oceananigans.jl/pull/283 and #306
https://github.com/climate-machine/Oceananigans.jl/pull/306) but it's a
work in progress and might not be the best use of our efforts right now.
Reference: Catherine A. Vreugdenhil and John R. Taylor, Large-eddy
simulations of stratified plane Couette flow using the anisotropic
minimum-dissipation model
https://aip.scitation.org/doi/abs/10.1063/1.5037039, Physics of Fluids
30, 085104 (2018).
cc @glwagner https://github.com/glwagner @rafferrari
https://github.com/rafferrari
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/climate-machine/Oceananigans.jl/issues/310?email_source=notifications&email_token=AKXUEQWVAM5WA445JVSWDZ3P6XQFBA5CNFSM4H7PMRLKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G6LLIOA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKXUEQSSGRFFX26YFGPJV43P6XQFBANCNFSM4H7PMRLA
.

@ali-ramadhan thanks for looking into that!
I think a convergence test with coarse horizontal resolution and varying vertical resolution is probably a good idea, perhaps producing a plot like Fig 11 in Vreugdenhil and Taylor.
In my reading, ∆y_w^+ is the vertical spacing in 'wall units', which is the physical spacing divided by nu/u_\tau, where nu is viscosity and u_\tau is the friction velocity defined in eq 16.
In Table II, values for both ∆y_w^+ and ∆y_c^+ (grid spacing at wall and at domain center) are given. It looks like many of the runs may be feasible. Here's some code:
 y(j, Ny, Sf, h) = h / tanh(Sf) * tanh(Sf*(2*(j-1)/Ny - 1))
Δy(j, Ny, Sf, h) = y(j+1, Ny, Sf, h) - y(j, Ny, Sf, h)

N_unstretched(Ny_VT, Sf) = ceil(Int, 2 / Δy(2, Ny_VT, Sf, 1))

@show N_unstretched(49, 3)
@show N_unstretched(65, 2.5)
@show N_unstretched(97, 3)
@show N_unstretched(129, 2)

It looks like some of their runs are feasible, since
julia> N_unstretched(49, 3) # runs 2-4
1141

julia> N_unstretched(65, 2.5) # run 5
768

julia> N_unstretched(97, 3) # runs 7-11
2710

julia> N_unstretched(129, 2) # run 12
805

Runs B-G (which are included to demonstrate resolutions that are apparently inadequate) may also be feasible.
One concern about the suitability of stratified Couette flow is mentioned at the end of the paper...

Stratified plane Couette flow is a challenging test case
for the LES model because it has a linearly stable laminar
state which introduces requirement 1. The results of Abkar
and Moin13 suggest that AMD LES performs even better in
other stratified wall-bounded flows. Balancing all these concerns
is key to using the AMD model in LES of wall-bounded
stratified flow. Nevertheless the AMD model is able to capture
turbulent intermittency and mean and turbulent flowproperties
in stratified plane Couette flow.

@johncmarshall54 we are planning to implement stretched vertical grid functionality after the LES is implemented.

Ali, i thought the stretching was sorted now, after the hackathon. Without stretching the code will have limited use. John

Yes well, we know how to do a very fast Poisson solve in a vertically stretched grid but still working on integrating it (PR #306). The fast solver (which relies on cyclic reduction) may need some massaging to work with Neumann boundary conditions for pressure...  I divided by Ny-1 by mistake. The matching factor of 0.35 might have been pure coincidence.
We need closer to O(1000) vertical levels, which should be pretty doable.

Temperature and velocity profiles look qualitatively correct which is promising but the sub-grid-scale viscosity and diffusivity don't match. At least the order of magnitude on each is roughly correct.
Most notably their version of AMD allows the SGS ν and κ to go below the background values, which seems essential for ν, although not sure what that physically means. Seems that the VerstappenAnisotropicMinimumDissipation closure in the new-closures branch allows for this so I'll try rerunning with it.
The SGS profiles seem kind of noisy but maybe I just need to bump up the resolution.
The SGS/turbulent Prandtl number is still too low but this should get fixed if the SGS ν and κ profiles are right.
The wall velocity Uw=1 so the x-axis is U/Uw.

The wall temperature is Tw = 0.01 so this plot should match the profile from Vreugdenhil & Taylor.

I won’t get the chance to look closely at these profiles until later, but
here are some thoughts in the intervening time:
The nonlinear, subgrid scale diffusivities model the effect of unresolved,
subgrid scale turbulence on the resolved flow. This is their physical
meaning. When the SGS diffusicities are 0, this physically means that there
is no subgrid scale turbulence. This occurs when turbulence is completely
resolved or if there is no turbulence, as in the case of laminar flow. In
the stratified couette example, the near-wall motions are “resolved”, so
that near the wall the SGS diffusivities should vanish. This is because the
near wall motions are nearly laminar (very strongly sheared) with only
small turbulence fluctuations. The interaction of the flow with the wall is
not part of the AMD model, which means that this part of the flow must
either be resolved or modeled with a “wall model”, which somehow accounts
for the effect of wall effects on the nonlinear subgrid scale
diffusivities.
When the nonlinear diffusivities are calculated in Oceananigans, the
constant molecular contribution is added so that the resulting diffusivity
field is the sum of the nonlinear and molecular components.  Therefore to
calculate the nonlinear part correctly from a saved diffusivity field, the
molecular value must subtracted. This behavior is identical between
RozemaAnisotropicMinimumDissipation and
VerstappenAnisotropicMinimimDissipation.
Because of the fact that this experiment requires near wall motions to be
resolved to be correct, the results should depend strongly on resolution.
On Sun, Aug 18, 2019 at 7:11 AM Ali Ramadhan<EMAIL_ADDRESS>wrote:

Temperature and velocity profiles look qualitatively correct which is
promising but the sub-grid-scale viscosity and diffusivity don't match. At
least the order of magnitude on each is roughly correct.
Most notably their version of AMD allows the SGS ν and κ to go below the
background values, which seems essential for ν, although not sure what that
physically means. Seems that the VerstappenAnisotropicMinimumDissipation
closure in the new-closures branch allows for this so I'll try rerunning
with it.
The SGS profiles seem kind of noisy but maybe I just need to bump up the
resolution.
The SGS/turbulent Prandtl number is still too low but this should get
fixed if the SGS ν and κ profiles are right.
The wall velocity Uw=1 so the x-axis is U/Uw.
[image: plots_stratified_couette_flow_u_profiles]
https://user-images.githubusercontent.com/20099589/63219768-2343de80-c147-11e9-8591-7d52fe4a27c5.png
The wall temperature is Tw = 0.01 so this plot should match the profile
from Vreugdenhil & Taylor.
[image: plots_stratified_couette_flow_T_profiles]
https://user-images.githubusercontent.com/20099589/63219770-26d76580-c147-11e9-83e1-f8a076dc7810.png
[image: correct_profiles]
https://user-images.githubusercontent.com/20099589/63219833-4fac2a80-c148-11e9-8a0e-55d8b31b541a.png
[image: plots_stratified_couette_flow_nu_profiles]
https://user-images.githubusercontent.com/20099589/63219836-55097500-c148-11e9-811c-e520e8dd1c4b.png
[image: plots_stratified_couette_flow_kappaT_profiles]
https://user-images.githubusercontent.com/20099589/63219837-589cfc00-c148-11e9-8ff9-e9afc5f69472.png
[image: correct_SGS_profiles]
https://user-images.githubusercontent.com/20099589/63219838-5b97ec80-c148-11e9-800e-7b3a9923511e.png
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/climate-machine/Oceananigans.jl/issues/310?email_source=notifications&email_token=ADUQQBTLE6XCGRLSC2QHD7LQFEU5DA5CNFSM4H7PMRLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4Q5U2Y#issuecomment-522312299,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADUQQBWKU7TT45JZYQO5CJTQFEU5DANCNFSM4H7PMRLA
.

Thanks for the explanation @glwagner.
I didn't realize that the background diffusivity had to be subtracted from the nonlinear diffusivity. In that case the ν isn't super far off although both nonlinear diffusivity profiles (especially the κ profile)  suggest that perhaps the boundary layer is not being resolved.
I'm rerunning the simulation but with the vertical resolution tripled. Hopefully this will improve the comparison.

@ali-ramadhan a few more comments:

I don't understand why the temperature profiles you've plotted have spikes in them, especially since they are horizontal averages. What's going on? The sub grid scale diffusivities also seem to have far too much variance.

Can you plot multiple equilibrated horizontally averaged solutions for differing model constant C? I think we may need to determine the correct value of this constant for our numerical method in order for our results to match. It looks like the SGS diffusivity values are too small, so this might help...

We can't be sure what resolution an Oceananigans.jl model needs to be to match Diablo results, since Diablo uses a spectral discretization in the horizontal. That's something to keep in mind. Note also that V&T take the spectral discretization into account when defining their 'filter widths' in their AMD implementation.

If our results matched Diablo without resolving the viscous boundary layer near the walls, I think this would not constitute a verification of Oceananigans (instead, it would indicate a problem with Oceananigans, or the presence of some kind of 'cancellation of errors'). We must resolve the viscous boundary layers near the walls in this experiment for the results to be valid.

For reference, the AMD viscosity is calculated here:
https://github.com/climate-machine/Oceananigans.jl/blob/352c018b6cb8801500bae61ac858ddc146bf3f48/src/turbulence_closures/anisotropic_minimum_dissipation.jl#L50
the diffusivities are similar.

Just to document what's been done:
So I ran the Ri = 0.01, Pr = 0.7 case that Cat ran at three different horizontal resolutions and unfortunately the results are quite different from hers:

U and T don't fully go to zero at the top and bottom. This could be because we only have 64 vertical levels, not enough to resolve the boundary layers, but otherwise the profiles look qualitatively correct.
Our νSGS/ν and κSGS/κ are too low by a factor of ~2. They decrease as you increase the resolution which makes sense. κ profile shape looks similar to Cat's. ν profile shape should be flatter.
Re is roughly a factor of 2 too large. Nu is too large by ~60%. (edited)
I might try changing the Poincare "constant" to see if it makes a difference here. Currently C = 1/12, so I'll try 1/24 and 1/6. Might also try 128 vertical levels, but that's no longer a fair comparison.

To make sure it's not just low resolution being bad, I reran everything at 256x256x128 (to keep aspect ratio the same).
SGS diffusivity profiles look okay at C = 1/6 (although shapes still don't fully match Cat's) so it's also possible that I'm calculating Re and Nu incorrectly...

So going up to 256x256x128 didn't help. Re and Nu don't actually change much. (edited)
Re and Nu are still too big by a factor of ~2...

Apparently I'm just an idiot.
h = model.grid.Lz
Reτ = h * √uτ²⁺ / ν
Nu = (qw⁺ * h)/(κ * Θw)

The height of the domain is actually 2h based on the domain geometry described in Cat's Table 1. So I should have used h = model.grid.Lz / 2.
There's the factor of 2.

🤷♂🧠🏃♂🙉🦉

How does the flow field look?

Rerunning Ri = 0.01 and Ri = 0.04 to make sure both come out matching Cat's simulations.
Will also plot some flow fields from the 256x256x128 runs to see what they look like.

I am not sure I understand the definitions of Re and Nu. Re should be a velocity scale times a length scale divided my nu. Nu should be the ratio of the adjective heat flux w theta over the diffusion heat flux kappa grad theta.
Raffaele

On Sep 6, 2019, at 7:31 AM, Ali Ramadhan<EMAIL_ADDRESS>wrote:
Apparently I'm just an idiot.
h = model.grid.Lz
Reτ = h * √uτ²⁺ / ν
Nu = (qw⁺ * h)/(κ * Θw)
The height of the domain is actually 2h based on the domain geometry described in Cat's Table 1. So I should have used h = model.grid.Lz / 2.
There's the factor of 2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@rafferrari
√uτ²⁺ is a velocity scale (it's written oddly I think...), h is a length scale, and ν is ν.
@ali-ramadhan should correct me, but it looks like κ * Θw / h is a diffusive heat flux scaling across the domain, whereas qw⁺ is the wall temperature flux (not sure how its calculated).

The Nusselt number here is the ratio between the measured turbulent temperature flux and the temperature flux we expect in the laminar solution?

I thought one of the advantages of Julia is that one can use easy to read notation. The notation for Re and Nu is anything but intuitive. Should we discuss how to improve on that?
Raffaele

On Sep 6, 2019, at 8:08 AM, Gregory L. Wagner<EMAIL_ADDRESS>wrote:
@rafferrari
√uτ²⁺ is a velocity scale (it's written oddly I think...), h is a length scale, and ν is ν.
@ali-ramadhan should correct me, but it looks like κ * Θw / h is a diffusive heat flux scaling across the domain, whereas qw⁺ is the wall temperature flux (not sure how its calculated).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@rafferrari we're using the frictional Re and Nu as defined by equation (20) of Vreugdenhil & Taylor (2018).
frictional Re = (friction velocity) * (domain height / 2) / ν

Re is still a velocity scale U times a length scale L divided by ν just with specific choices for U and L.
@glwagner Yeah it's written a little oddly as we can easily calculate the friction velocity squared (which I then take square roots of), but perhaps the script will be clearer if I just use uτ.
The superscript + and - indicate the top and bottom wall values, but as @glwagner has pointed out the superscript + is reserved for wall units so perhaps I need to improve my notation here as well.

I thought one of the advantages of Julia is that one can use easy to read notation. The notation for Re and Nu is anything but intuitive. Should we discuss how to improve on that?

Yes there's definitely room for improvement here.

@ali-ramadhan how is qw calculated?
Are you sure your definition of Nu is correct? I would interpret it this way:
Laminar solution heat flux = Θw κ / h
(Because the wall-to-wall temperature difference is 2Θw , and the wall spacing is 2h, so the laminar temperature gradient would be Θw/h.)
Turbulent heat flux = qw.
Then
Nusselt number = Turbulent heat flux / laminar heat flux = qw * h / (Θw * κ).
I'll review the notation in the pull request.

@glwagner Quite possibly.
qw is calculated from equation (16) of Vreugdenhil & Taylor (2018)
qw = (friction velocity) * (friction temperature)

Thanks @ali-ramadhan.
For the record, this means that its
qw = κ ∂y Θ |_wall
aka, the heat flux out of the wall.
(In V & T, y is the wall-normal coordinate.)
@ali-ramadhan technically we should be using the total diffusivity (LES + molecular) to calculate qw (because these new coarse simulations do not resolve the wall boundary layer). Since the SGS diffusivity is quite small (some fraction of the molecular diffusivity), this correction may not be huge.

Terrible notation in my humble opinion. w stands for vertical velocity. Why is the advective heat flux qw instead of w theta?
Raffaele

On Sep 6, 2019, at 9:58 AM, Gregory L. Wagner<EMAIL_ADDRESS>wrote:
Thanks @ali-ramadhan https://github.com/ali-ramadhan.
For the record, this means that its
qw = κ ∂y Θ |_wall
aka, the heat flux out of the wall.
(In V & T, y is the wall-normal coordinate.)
@ali-ramadhan https://github.com/ali-ramadhan technically we should be using the total diffusivity (LES + molecular) to calculate qw (because these new coarse simulations do not resolve the wall boundary layer). Since the SGS diffusivity is quite small (some fraction of the molecular diffusivity), this correction may not be huge.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/climate-machine/Oceananigans.jl/issues/310?email_source=notifications&email_token=AK24ROM5GSG5ZSWBZ5KICRTQIJOXJA5CNFSM4H7PMRLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6C5R3Q#issuecomment-528865518, or mute the thread https://github.com/notifications/unsubscribe-auth/AK24ROM3CIZRZH5K2POAN73QIJOXJANCNFSM4H7PMRLA.

@rafferrari I agree about that --- it comes from engineering, where the vertical velocity is "u₂"...
These simulations run to steady-state, in which case the horizontally averaged total vertical temperature flux is constant at every level. Thus it is sufficient to calculate the heat flux at the wall.
Technically speaking, the Nusselt number is the ratio between turbulent heat flux and laminar heat flux. In situations with strong turbulence of course the heat flux is dominated by the advective component... ? In LES we need to be somewhat delicate, because the total heat flux includes "resolved-advective" and "unresolved-advective" (subgrid scale) components. Luckily in equilibrated problems these distinctions are moot.

Terrible notation in my humble opinion. w stands for vertical velocity. Why is the advective heat flux qw instead of w theta?

We should improve it before merging the test and polishing it off. @glwagner also suggested agreeing on some common notation for our papers.
Following the V&T paper it's q_w (subscript w for wall) but there is no subscript w in Unicode (or if there is, it's not available in Julia) so I ended up writing qw but maybe q_w, qʷ, or even q_wall would be better notation.

+1 for q_wall for the purposes of this verification example.

So I reran the simulations with Ri = 0.01 and Ri = 0.04 to compare with Cat's coarse uniform grid DIABLO simulations.
Some comments:

Horizontally averaged velocity and temperature profiles look qualitatively correct. Oceananigans Ri = 0.01 velocity curve could be smoother but perhaps we just need higher resolution.
ν and κ profiles are different. Oceananigans' magnitude is lower and shape is a bit different. Perhaps this is expected due to differences in the numerical method. Perhaps the Poincaré "constant" needs to be set to a suitable value for our finite volume numerics. Maybe we don't expect exact agreement here.
Most importantly, the frictional Reynolds (Re) and Nusselt (Nu) numbers match more closely now. Re values are within ~10% of each other. Oceananigans Nu values are ~20% smaller. Probably higher resolution is required to match more closely with Diablo and DNS?
Oceananigans uses z for the vertical direction while DIABLO uses y.


preparing metadata did not run successfully when downloading lsl

Hi,
I met the following error when downloading pylsl on Windows machine with python 3.10.10:
any suggestions for it?

Thanks!

I don't know what the python package lsl is but it's not this project.
pip install pylsl


LDAP Errors with Upgrade to PHP 8

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
After the upgrade to 22.7, auth calls to my ldap server are failing with the following error.
Fatal error: Uncaught TypeError: ldap_get_entries(): Argument #2 ($result) must be of type resource, bool given in /usr/local/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php:596 Stack trace: #0 /usr/local/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php(596): ldap_get_entries(Resource id #50, false) #1 /usr/local/www/diag_authentication.php(57<EMAIL_ADDRESS>'Password1$') #2 {main} thrown in /usr/local/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php on line 596
I suspect this has to do with the upgrade to PHP 8, but I am not familiar enough with PHP to know where to look next.
To Reproduce
Steps to reproduce the behavior:

Create an ldap connection using the Okta virtual ldap
Upgrade to 22.7
LDAP calls fail with the given error

Expected behavior
I would expect the ldap calls to authenticate successfully as worked in the same configuration for previous opnsense versions.
Describe alternatives you considered
Downgrading back to 22.1.10 fixes the issue
Screenshots
ldap server configuration

Testing the auth

Failure

Relevant log files
 | LDAP bind error [Authentication failed : (Refer to Okta error Code E0000004); Invalid credentials]
The following was noticed during the upgrade, not sure if relevant.
2022-08-11T20:28:01 | Error | opnsense | /usr/local/etc/rc.configure_firmware: warning: ignoring missing default tunable request: net.inet.ip.fastforwarding
Additional context
N/A
Environment
Software version used and hardware type if relevant, e.g.:
OPNsense 22.1.10_4-amd64
FreeBSD 13.0-STABLE
OpenSSL 1.1.1q 5 Jul 2022

@JamieOrlando-Engooden can you try https://github.com/opnsense/core/commit/bc392461da6e1fe79cd2aeb9c22214137f88906f? I haven't had time to check this locally yet, but it looks like a classic php 8 change.
This should install the patch via a console:
opnsense-patch bc39246

Thank you very much @AdSchellevis . I can confirm this fixed the issue I was running into.

@JamieOrlando-Engooden thanks for letting us know, we'll try to queue this one for 22.7.2


Why AbstractFreeSpec.FreeSpecScope String.config test function is not suspend

Why AbstractFreeSpec.FreeSpecScope method suspend fun String.config have argument test with type FreeSpecScope.() -> Unit not test: suspend FreeSpecScope.() -> Unit ?
In current state i can't test suspend functions

Fixed, will be in 4.0


Crash in - (void)setIdentity:(NSString *)userId

If user session is not yet initialized when call to setIdentity the app crash trying to create the post dictionary because [BNCPreferenceHelper getDeviceFingerprintID], [BNCPreferenceHelper getSessionID], [BNCPreferenceHelper getIdentityID] return nil values.

@ralonsocf Hmm, there should be blocks to prevent those requests from going through if that's not initialized, but perhaps it's not correct. Will check and fix for you -- sorry about that.

Ah, there is a check, but the request bodies are being constructed too early. This will be fixed by an outstanding pull request, which should be in this afternoon I hope.

Thanks Graham!

any update about the fix release?

Sorry for the delay, just waiting on review of #113. Hopefully will have it out by early next week.

Hi guys, the update has been released! Please give it a shot, and let us know if you run into any problems. Sorry about that :frowning:


Question re: max_connections and SQL table alteration

Is your feature request related to a problem? Please describe.
Is it possible in the config options to increase the max_connections to the database?
Can you please provide some guidance on altering the query in the additional context section or what im missing in my container? When I try to alter that table as in a previous issue where you describe your installation I get the message:
ERROR:  function isnumeric(text) does not exist
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.
SQL state: 42883

Like what you mentioned about columns requiring a numeric value in your grafana setup that’s where I am too.
Describe the solution you'd like
I have a feeling im just not versed enough in docker and this is an easy change, but I’d like to increase the max connections to the db session to be higher than 20. It appears that each time the container restarts it re tunes itself and overwrites any changes to postgresql.conf that are manually made
With the SQL query, can you guide me on that or point to where I’m going wrong? Thank you, the plugin is very functional for extending the functionality of postgres with timescaledb for grafana’ing
Additional context
Add any other context or screenshots about the feature request here.
max_connections = 50
ALTER TABLE public.ltss
    ADD COLUMN state_numeric double precision GENERATED ALWAYS AS (
CASE
    WHEN isnumeric((state)::text) THEN (state)::double precision
    ELSE NULL::double precision
END) STORED;

Hi @songo-github !
Thanks!
I see that the script indeed misses the isnumeric() function.
You can create it with the script below, and I added it to the post:
CREATE OR REPLACE FUNCTION public.isnumeric(
	text)
    RETURNS boolean
    LANGUAGE 'plpgsql'
    COST 100
    IMMUTABLE STRICT PARALLEL UNSAFE
AS $BODY$
DECLARE x NUMERIC;
BEGIN
    x = $1::NUMERIC;
    RETURN TRUE;
EXCEPTION WHEN others THEN
    RETURN FALSE;
END;
$BODY$;

ALTER FUNCTION public.isnumeric(text)
    OWNER TO postgres;
```

As for the connections, it's true that the TimescaleDb tune is tuning on every container restart, but this should not overwritre your manual changes to that file.

But I'm curious, why increasing the max_connections? Are you hitting the limit with Home Assistant? Or do you also run a lot of other stuff on it?

Hi @songo-github,
I've just release  v1.1.6
This added the option to set the max connections from the configuration.
Thanks for bringing this up.

Thank you, your guidance worked perfectly! Fantastic add on. Since switching to time series for all the graphs I haven't observed any wayward grafana connections to the Postgres db. Those were what was causing the error message "remaining connections reserved for non super user..." message that grafana displayed.
For what it's worth, when I increased the max memory to 2048 the tuning itself changed the max connections to 50 instead of 20